2 Background: Pre-OO Criteria for Modularity

Much of the discussion and motivation of SOLID harks back to some basic ideas of what constitutes a good “module” or division of a program into modules, from before the time when classes were the primary unit of modularity, when few programming languages had any built-in concept of a module fo gathering and organizing groups of related functions.

2.1 Information Hiding

3 Single Responsibility Principle (SRP)

The Single Responsibility principle (Robert Martin, 2003) is a refinement of the idea of information hiding. It applies information hiding specifically to classes, and reinforces the original idea that our choices stem from our preparation for possible future changes.

> A class should have only a single reason to change.

For example, we might consider some additions to our familiar Book class:

class Book {
public:
  ⋮

  /**
   *  Write a description of this book, properly formatted
   *  for the publisher's quarterly catalog.
   */
  void writeCatalogDescription (std::ostream&) const;

  /**
   * Update master record in publisher database with any
   * changes made to this book.
   */
  void save (PublisherDatabase& db) const;

};

Now, consider some possible changes to be made to the Book:

1. We might need to add new attributes or change the implementing data structures used for the “core” book metadata, such as titles, authors, etc.

2. The publisher might decide to switch the catalogs from a paper format to an online format, so that the output of writeCatalogDescription might now need to emit HTML tags.

3. The publisher might change database formats, or redesign the record structure in the databases.

If we considered all three of these changes to be equally plausible, that imply that neither of these two new functions should be incorporated into the Book class.

If we consider the first change to be unlikely, but the other two to be plausible, we might accept placing one of these two functions into the Book class, but not both. (There are other reasons, unrelated to this principle, arguing against putting writeCatalogDescription here.)

SRP is also related to an older idea you might recall from CS250/333,

4 Open Closed Principle (OCP)

Formulated by Bertram Meyer (1988):

Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

What does this mean? Well, “extension” and “modification” are again speaking to the potential for future changes.

This principle challenges us to plan for future changes so that we will rarely have to edit and recompile existing classes, but will instead introduce new classes for this purpose.

The most common mechanism for doing this is the combination of inheritance with the ability to override member functions, supplying the desired new behavior in an overridden function body supplied in a new subclass. Now, doing this effectively requires planning. We have to

1. anticipate, when we design the base class(es) in our inheritance hierarchy, just what kind of new behaviors are likely to be requested in the future , and

2. design, in the base class, an function or group of related functions that can successfully embody the range of likely new behaviors.

Consider, for example, the design of the expressions in our spreadsheet program. We might start off with a list of possible operators like basic arithmetic (+ - * /) and a few functions (e.g., sqrt), but it seems likely that this list will grow rapidly. How do we plan for that?

We look at what is likely to be different from one operator to the next:

1. the number of operands
2. what the operator does to the values of those operands in order to calculate a result, and
3. the way in which the operator is printed when displaying an expression
4. the way the operator is recognized when encountered as part of an expression.

Then we isolate those behind various function members:

5 Liskov Substitution Principle (LSP)

Barbara Liskov in 1988 formulated the principle that

Subtypes must be substitutable for their base types.

5.1 Example: A Bird in the Hand

Consider this inheritance hierarchy:

 class Animal;
 class Bird: public Animal { ...
 class BlueJay: public Bird { ...

Nothing too surprising there, right?

Let’s postulate some members for Birds:

 class Bird: public Animal {
    Bird();
    double altitude() const;
 
    void fly();
       // post-condition: altitude() > 0.
      ⋮
 };
 
 class BlueJay: public Bird
 {
     ⋮

And I really want to focus on the expected behavior of fly(), which I have documented with a post-condition. If I tell a bird to fly, it should get off the ground.

5.1.1 Is an Ostrich a-kind-of Bird?

 class Ostrich: public Bird
 {
   Ostrich();
   // Inherits
   // double altitude() const;
 
   // void fly();
   //post-condition: altitude() > 0.

Now, Ostrich can provide its own method for fly(), overriding the default implementation.

 void Ostrich::fly()
 //post-condition: altitude() > 0.
 {
   plummet();
 } 

but it can’t satisfy that post-condition.

• An unpleasant surprise for a program traversing a list of Birds and telling them each to fly().

5.1.2 Substitutability

The ostrich/bird hierarchy violates the substitutability principle.

• You can view this dilemma as a failure of analysis:

  • Who said all birds could fly?

  • A FlyingBirds subclass of Bird would clarify the situation.

    BlueJay could go into that new subclass, but Ostrich would not.

(Anyone want to tackle classifying a platypus?)

Martin’s examples of Squares versus Rectangles and Lines versus LineSegments are particularly instructive examples of how subclasses may be perfectly legal in a language, yet be awkward to work with because they violate expectations.

5.1.3 What Happens If You Get It Wrong?

Violations of the LSP generally result in classes where the behaviors are non-intuitive, have surprises (we’ve mentioned before Booch’s “principle of least surprise” that suggests that surprises in a design are almost always unfortunate), or have strange bits of hackery – obscure code designed to force subclasses to behave as expected or to work around subclasses that are known to not to the expected thing.

6 Dependency-Inversion Principle (DIP)

Robert Martin named this in 1996.

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.

2. Abstractions should not depend upon details. Details should depend upon abstractions.

Again, it’s tempting to dismiss this as something that is already enforced by almost any programming language, because it is possible to view “high-level” and “abstract” in terms of how we have already written the code instead of as a property of our underlying abstractions.

Let’s think about this in the context of our Spreadsheet example. A Spreadsheet can contain many different kinds of values. Some contain numbers, others contain strings, others might contain dates, monetary amounts, or still other types of data. Typically there is a special kind of “error value” that is stored in a cell when we have formulas that do something “illegal”, such as dividing a number by zero or adding a number to a string.

There are some things we expect to be able to do to any value, e.g.,

  string render(int width)
  Value* clone()

For values to be useful in a spreadsheet, we must be able to render them in a cell whose current column is of some finite width. The render function, in general, could be quite elaborate. For example, given a lot of room, we might be able to render a number as 12509998.0. If we sharing the column containing that cell, though, we might need to render it as 12509998. Shrink it some more and we might need to render it as 1.25E06. Shrink a little more, and we might need to say 1.3E06, then 1E06. Shrink the available space small enough, and a spreadsheet will typically render a number as “***”.

There may be other operations required of all values as well, such as clone().

Now, the information we have provided so far is general to all values.

But to actually store a numeric value, we need a data member to hold a number (and a function via which we can retrieve it, though we’ll ignore that for the moment). Similarly, we can expect that, to store a string value, we would need a data member to store the string.

We will assume, therefore, that

• Numeric values have an attribute d of type double.

• String values have an attribute s of type string.

6.1 A pre-OO Approach to Variant behavior

 class Value {
 public:
   enum ValueKind {Numeric, String, Error};
   Value (double dv);
   Value (string sv);
   Value ();
 
   ValueKind kind;
   double d;
   string s;
 
   string render(int width) const;
 }

Now, if we had never heard of inheritance (of if we were programming C, FORTRAN, Pascal, or any of the other pre-OO languages, we might have come up with an ADT something like this. (Actually, there are ways to make this more memory-efficient in those languages using constructs called “unions” or “variant records”, but they would not change the point of this example.)

• Any given value will presumably have something useful stored in d or in s, but not in both.

  • In the case of an error value, it may not have anything useful in either one.

• kind is a “control” data field.
  • It does not actually store useful data of its own.
  • It’s there to tell us which of the variants of value we have stored in any particular value.
  • We’ll use this mainly so that we can branch to code appropriate to that variant.

Multi-Way Branching

Functions that work with this kind of value do the bulk of their work inside multi-way branches. For example, a Spreadsheet may periodically need to display the values in all cells currently visible on the screen:

 void Spreadsheet::refreshDisplay() const {
     for (Cell c: allVisibleCells())
     {
        Value* v = c.getValue();
        int columnWidth = ...;
        string rendered = v->render(columnWidth); 
        displayValueInCell (c, rendered); 
     }
 }


 string Value::render(int width) const {
   switch (kind) {
     case Numeric: {
       string buffer;
       ostringstream out (buffer);
       out << d;
       return buffer.substr(0,width);
       }
     case String:
       return s.substr(0.width);
     case Error:
       return string("** error **").substr(0.width);
   }
 }

For example, to write the body for the render function, we would probably do something like this. First, we do a multi-way branch on the kind to get to the appropriate code for a numeric, string, or error value. Then in each branch we use a different technique to render the value as a string, then chop the string to the desired width.

• We can expect to see similar multi-way branches used to implement clone() or just about every other function we might write for manipulating Values.

Now, if we want to promote information hiding, we might realize that we are embedding a lot of separate design decisions about rendering of different types of values into that one render function. Let’s isolate those into distinct modules:

 string Value::render(int width) const {
   switch (kind) {
     case Numeric:
       return NumericValue::renderNumeric (*this, width);
     case String:
       return StringValue::renderString (*this, width);
     case Error:
       return ErrorValue::renderError (width);
   }
 }

 ⋮

 class NumericValue {
 public: 
   static string renderNumeric (const Value& v, int width) 
   {
       string buffer;
       ostringstream out (buffer);
       out << v.d;
       return buffer.substr(0,width);
   }
  };   

 class StringValue {
 public: 
   static string renderString (const Value& v, int width) 
   {
       return v.s.substr(0.width);
   }
  };   

 class ErrorValue {
 public: 
   static string renderError (int width) 
   {
       return string("** error **").substr(0.width);
   }
  };   

And if we look at the dependencies involved, we see that the Spreadsheet class that requests the rendering in the first place, depends on Value, which in turn depends on each of the specialized value classes.

6.2 Variant Behavior under OO

Now, compare that with the OO approach.

 class Value {
 public:
   virtual string render(int width) const;
 };

 class NumericValue: public Value {
 public:
   NumericValue (double dv);

   double d;

   string render(int width) const;
 };

 class StringValue: public Value {
 public:
   StringValue (string sv);

   string s;

   string render(int width) const;
 };

 class ErrorValue: public Value {
   ErrorValue ();

   string render(int width) const;
 };

• We represent each variant with a distinct subclass.

  • Only objects of the NumericValue class get the d data member.
  • Only objects of the StringValue class get the s data member.
  • None of them get the kind data member.

• This saves memory when we have large numbers of values floating about (as in a very large spreadsheet).

• But what’s more important is how it affects the code we write for manipulating Values.

6.2.1 Variants are Separated

 void Spreadsheet::refreshDisplay() const {
     for (Cell c: allVisibleCells())
     {
       Value* v = c.getValue();
       int columnWidth = ...;
       string rendered = v->render(columnWidth); 
       displayValueInCell (c, rendered); 
     }
 }

 string NumericValue::render(int width) const
 {
   string buffer;
   ostringstream out (buffer);
   out << d;
   return buffer.substr(0,width);
 }


 string StringValue::render(int width) const {
   return s.substr(0.width);
 }

 string ErrorValue::render(int width) const {
   return string("** error **").substr(0.width);
 }

Here’s the OO take on the same render function.

• None of the details of how to render specific kinds of value have been changed.

• But we have repackaged that code into subclass-specific bodies.

  • The “variants” are now separate. In a team environment, different people can work on different variants separately.

  • Each subclass operation is simpler.

  • Most important of all, new kinds of values can be added without changing or recompiling the code of the earlier kinds of values.

Suppose, for example, that we later decide to add to our spreadsheet the ability to manipulate dates. In the pre-OO style, we would need to look through all our code for any place we had a multi-way branch on the kind, then add a new branch with code to handle a date. Heaven help us if we miss one of those branches! If we’re lucky, our code will crash during testing when we hit that branch with a date value. If we’re unlucky, the crash occurs just as we’re demo’ing the spreadsheet to upper management.

By contrast, to add dates in the OO style, we declare DateValue, a new subclass of Value. We write the code to render date values (which we would have to do in any case) and put it in its own DateValue::render body. Link it with the existing code, and we’re ready to go. None of the existing code had to be touched at all.

6.3 Where’s the Inversion?

Why is this called “dependency inversion”?

Remember that our pre-OO, multi-way branching approach gave us dependencies that look like this.

The arrows show interface dependencies, but they also illustrate the directions of the calls being made. It sort of makes sense, after all, to think that if you want to call a function in a class, you must “see” and therefore be dependent on that class’s interface.

At least, that makes sense until we start to mask our calls behind dynamic dispatch…

7 Interface Segregation Principle (ISP)

Robert Martin (2000):

Many client-specific interfaces are better than one general-purpose interface.

When we first learn about inheritance, we tend to focus on situations where we have a single parent class. Over time, base classes tend to acquire more and more public members, and they may wind up becoming quite unwieldy.

We have learned that we aren’t necessarily limited to inheriting from a single base. C++ allows multiple inheritance. Java only allows us to inherit from one base class, but we can also implement (be subclasses of) any number of interfaces.

Why would we bother?

If we are willing to be more flexible and define our classes’ behaviors in smaller (but still cohesive) pieces, we wind up with a vocabulary of simple interfaces to learn and use. More separate pieces, but they can be easier to learn and remember both as individuals and as groups.

7.1 A Negative Example: std Containers in C++

The C++ std library provides a variety of “container” data structures including: vectors, lists, deques, sets, and maps. In CS361, I try to tell students that there are a lot of common patterns to look for in these:

• You can insert and erase elements in all of them.
• You can request the size() of all of them and ask if they are empty().
• You can add to the end of a vector, list, or deque using push_back.
• You can add to the end of a list or deque using push_front.
• All of them provide iterators and can be used in range-based for loops.
• Each of them provides a default constructor and a constructor that accepts a range of input values expressed as a pair of iterators.

And that’s all very well and good, but it still falls on the programmer to remember which of these common operations apply to all the containers and which ones apply only to some of the containers.

7.2 A Positive Example: Standard Containers in Java

By way of contrast, let’s look at the opening lines of the Java interface for LinkedList:

public class LinkedList<E> extends AbstractSequentialList<E>
                           implements Serializable, Cloneable,
                           Deque<E>, Queue<E> {

So this class has a single base class, declared as

public class AbstractSequentialList<E> extends AbstractList<E> {

which in turn inherits from

public class AbstractList<E> extends AbstractCollection<E>
                           implements List<E> {

which in turn inherits from

public class AbstractCollection<E> 
                           implements Iterable<E>, Collection<E>
                    {

Now let’s look at all of the little bits that are being inherited or subclassed. I’m going to hit the highlights here, so this is a simplified treatment that skips some less critical functions.

• Iterable<E> means that it provides an iterator, obtained by calling the function iterator().

  By implication, we can use this in range-based for-each loops.

• Collection<E> means that we can add elements with add(...), clear() the container, check to see if it contains an element with contains, ask if it isEmpty() or what its size() is, and remove(...) elements.

• An AbstractCollection is pretty much just a name for anything that is both Iterable and a Collection.

• List<E> means that we can get(int) a position from an nteger numbered position or ask for the integer position indexOf(...) an element. We can als set data an an integer position.

  The List interface extends Iterable and Collection:

      public interface List<E> extends Collection<E>, Iterable<E>
      {
  

  so a “list” is pretty much a “collection” that you can use integer indexing on.

• An AbstractList is just a class version of List. Function bodies are supplied to implement the iterator in terms of the get and other operations, so new AbstractList subclasses can be created with less programming effort.

• An AbstractSequentialList is an AbstractList to which a private “sequential” (array-like) block of memory has been added. So now we are starting to see actual data structures come into play.

• Serializable provides operations for reading and writing data to a file or over a network pipe.

• Cloneable means that the clone() function can be used to make a copy.

• Deque<E> adds functions like addFirst and addLast, getFirst and getLast, etc., all of which are not absolutely necessary given the add and get functions, but which in some algorithms may be more descriptive.

So, what does all of this tell us?

1. Let’s be honest. It’s no easier to understand a Java LinkedList than a C++ std::list if you are coming to them for the first time.

2. But that vocabulary of interfaces is actually quite useful because they describe common practices in the Java world that we can use in our own code and announce to anyone reading our code that we have used.

   I use Iterable, Cloneable, and Serializable a lot in my own class designs. They describe things that I often want my classes to do, describe them in a way that is easily understandable, and help me to make sure that I am designing my interfaces in a “Java style”.

3. One of the important results of applying ISP is potential reduction in coupling. For example, if I am writing a class with a function that needs to loop through a collection of Books, I don’t necessarily need to depend on the specific collection type. For example, I can write:

   class BestSellerList {
          ⋮
       public void processAListOfBooks (Iterable<Book> bookList) {
           for (Book b: bookList) {
               doSomethingTo(b);
           }
       }   
          ⋮
    }
   

   and I can pass this function an ArrayList<Book>, a LinkedList<Book>, or any classes of my own design that implement Iterable<Book>:

   class PublishersCatalog implements Iterable<Book> {
        public void add (Book b) { ... }
        public Iterator<Book> iterator() { ... }
          ⋮
   }
   
   class BookShelf implements Iterable<Book> {
        public void add (int position, Book b) { ... }
        public Iterator<Book> iterator() { ... }
          ⋮
   }
   

   which means that BestSellerList might not need to depend on PublishersCatalog or BookShelf, even if we intend to use it with objects from those two classes.