Designing Abstractions

Lecture Notes for CS349W
Fall Quarter 2008
John Ousterhout

• The most fundamental element of computer science:
  • NOT algorithm design! Computers are fast enough to eliminate algorithmic considerations from most programming tasks.
  • The most important problem is managing complexity:
    • Technology allows us to build systems much larger than we can understand.
    • Biggest impediment to building computer systems is our ability to understand them.
    • Software complexity increases over time, system becomes brittle (changes too expensive or too dangerous).
  • Fundamental problem in computer science: decompose complex problems and systems into smaller units that can be understood in isolation.
  • I use the term "abstraction" to refer to these units.

• "Sweet" abstractions:
  • Minimum surface area for maximum volume: simple interface hides a lot of implementation complexity.
  • Easy to use:
    • Less code to type
    • Less to learn
  • Easy to make changes: impact of changes will be isolated inside an abstraction.
  • Reusability:
    • Same abstraction can be reused for many different tasks.
    • Abstraction provides a framework that allows many other components to be incorporated or work together.
  • Sometimes called "information hiding" or "separation of concerns":
    • Hide design decisions, such as a complex algorithm or data structure, behind a simple interface.
    • See classic article by David Parnas: "On the Criteria To Be Used in Decomposing Systems into Modules"
• Example of an unexciting abstraction: lists
  • List_First, List_Next, List_End
  • Alternative: directly use the pointers in the underlying data structures.
  • Too thin:
    • No implementation complexity to hide.
    • Interface not much easier to use than the underlying pointers.
  • Interface adds to system complexity.
  • (But, may be useful in terms of allowing construction of higher-level operations that will work for different kinds of lists, such as sorting).
• Example of a better abstraction: hash table
  • Simple interface:

    table.get(key) => value
    table.set(key, value)
    

  • Hides a lot of complexity:
    • Hash function for strings.
    • Table organization (link, chained, etc.)
    • Automatic restructuring as size increases
  • Reduced code size with interface versus without.
  • But, still not very substantial
• A great abstraction: pipes in Unix
  • Individual filters read from standard input, write to standard output.
  • Shell programs connect filters into pipelines.
  • Hides complexity within filters (e.g., grep, wc, sed, etc.)
  • Filters easy to reuse
  • Code reduction: tiny shell scripts can do powerful things
• How to find the sweet spot?
  • Facts precede concepts: examine a lot of code, look for common tasks (ElectricCommander example).
  • Separate the common case:
    • Powerful interfaces eventually need a lot of features, but most of them aren't used very often.
    • Identify the common case: "what's the simplest it can possibly be?"
    • First make the common case as simple as possible, then find a way to support the special cases without complicating the common case
      • Optional arguments
      • Additional methods to handle special cases
    • Make it easy to learn the common case without having to learn about fancy features; pick up the optional features one at a time, as needed.
  • Avoid classitis: more interfaces are not necessarily better!
    • Don't force people to use interfaces that aren't relevant for the common case.
    • Java I/O as an example of bad interfaces:
      • 50-100 Java classes and interfaces for simple I/O
      • Must use several classes/interfaces even for the most common case (open file, read buffered data)

        BufferedReader in = new BufferedReader(new FileReader(fileName));
        in.readLine();
        

      • Unix got the common case right, though it didn't provide as many intermediate access points

        FILE *f = fopen(fileName, "r");
        fscanf(f, "%s %d", ...);
        

    • Define the highest-level, most useful interfaces first; then fill in the intermediate interfaces if needed.
  • Allow customization/extension, but don't require it!
    • Provide good defaults.
    • .Xdefaults file as counter-example.
  • Minimize error handling:
    • Define errors out of existence: unset mistake in Tcl.
    • Centralized error handling: hide errors that can't normally be recovered from (Errors versus Exceptions in Java).
  • Don't introduce restrictions just because you can't imagine a reasonable use case
    • Property names in ElectricCommander.
    • No inherent size limits on tables, strings, etc.: grow automatically as needed.
    • Getting rid of restrictions simplifies the interface.
  • Are there things that nearly everyone will want? If so, just build them in automatically; don't make people ask for them.
  • Don't require explicit actions for things you can do on-demand:
    • Initialization
    • Loading from disk
• Some additional thoughts:
  • A great abstraction will be used in ways you never anticipated; don't assume you can anticipate all of the uses.
  • Move suffering inside the abstraction.
  • Hard for really smart people to design sweet interfaces because things don't seem complicated to them.
  • Plan on revisions: the first attempt is rarely sweet.
  • Sweat the details: the difference between a great abstraction and a clumsy one is often dozens of things each of which seems trivial.