1 The Observer Pattern

The Observer pattern is used when we need to maintain a “consistent” view of our data across many different data objects, some of which is likely to change values frequently.

There are two classes involved:

• the Observer

  • can ask an Observable object for notification of any changes

• the Observable

  • will keep track of a list of Observers and notify them when its state changes

1.1 Applications of Observer

1.1.1 Example: Propagating Changes in a Spreadsheet

Anyone who has used a spreadsheet has observed the way that, when one cell changes value, all the cells that mention that first cell in their formulas change, then all the cells the mention those cells change, and so on, in a characteristic “ripple” effect until all the effects of the original change have played out.

There are several ways to program that effect. One of the more elegant is to use the Observer pattern.

Cells Observe Each Other

class Cell: public Observable, Observer
{
public:

The idea is that cells will observe one another.

• Suppose cell B2 contains the formula “2*A1 + B1”.

• Then B2 will observe A1 and B1.

  It will use the Observable::addObserver function to add itself as an observer of both those cells.

• If something were to happen to A1 that changes its value (e.g., we click on A1 and then enter a new value), then

  • A1 will call notifyObservers(), which goes through its list of observers, including, eventually including B2, notifying each one.

  • When B2 is notified, it can re-evaluate its formula, change its value, and notify its observers.

Changing a Cell Formula

1.1.2 Example: Observer and GUIs

A spreadsheet GUI contains a rectangular array of CellViews. Each CellView observes one Cell

• When value in a cell changes, it notifies its observers as we have already seen. Some of those observers are other cells, as described earlier. But one of those observers might be a CellView.

• The observing CellView then redraws itself with the new value

Scrolling the Spreadsheet

Not every cell will have a CellView observer.

• That’s because most of the cells in a spreadsheet are not actually visible at a given time.

• Whenever we scroll the spreadsheet GUI, the CellViews each register themselves with a different cell, depending on how far we have scrolled.

1.2 Observer and SOLID

• Without the intervention of the abstract Observer class, all observables would need to directly make calls to their potential observers to notify them of changes.

  • Compared to that possibility, the Observer pattern inverts the dependencies (DIP).

• One might also make the argument that ISP is also in play, but this is mitigated by the fact that actual implementations of notify often wind up using downcasting on the observer parameter to get to the “real” subclass.

2 Model-View-Controller (MVC) Pattern

MVC is a powerful approach to GUI construction.

• Separate the system into 3 subsystems

  • Model: the “real” data managed by the program

  • View: portrayal of the model

    • updated as the data changes

  • Controller: input & interaction handlers

This pattern has many advantages. GUI code is hard to test. Keeping the core data independent of the GUI means we can test it using unit or similar “easy” techniques. We can also change the GUI entirely without altering the core classes. For example, my implementation of the spreadsheet has both a graphic form (as shown in the prior section) and a text-only interface that can be used over a simple telnet connection.

Separating the control code means that we can test the view by driving it from a custom Control that simply issues a pre-scripted set of calls on the view and model classes

2.1 MVC Interactions

How do we actually accomplish this?

• The Observer/Observable pattern is often exploited in MVC.
  • It allows the Model classes to notify appropriate parts of the GUI without knowing anything detailed about the GUI class interfaces.
    • (ISP at work)

2.2 MVC and SOLID

• The common use of the Observer pattern to implement views promotes DIP.
• The general separation of concerns is compatible with SRP.
• The restricted directions of interactions are directly aimed at avoiding unnecessary coupling.

3 Constructing Objects of Dynamically Selected Types

There are many situations where we need to create new objects, but the exact class that we want to use is not known at compilation time.

If that problem sounds familiar, compare it to “dynamic binding”, which comes into play when we want to call a function but the exact body that we want to use is not known at compilation time.

• But dynamic binding works by looking at the actual data type of the object being operator upon. That doesn’t help when we are trying to create a new object, because, if the object doesn’t exist yet, we can’t look to see what its type is!

• Or, to put it another way, constructors cannot be virtual. When we invoke a constructor, we say “new MyType(...)” and there’s no ambiguity about what type of object we are asking for, regardless of whether MyType is a base class or a subclass in some inheritance hierarchy.

But, consider the problem of parsing expressions for our spreadsheet program. Let’s suppose that we have a function that has just recognized that we have an operator that is written in the form

operator ( operand )

where operand is a subexpression that we have already parsed (for the sake of simplicity in this example, we’re only going to consider operators taking a single operand), and operator could be sqrt, or abs or sin or cos or possibly any of a number of functions to be added later to the spreadsheet program. We really don’t want our expression parsing code to look like:

static public Expression parse(Expression e) {
    Expression[] operands;
    String operatorName = ...;
    ⋮
      // We have found the operatorName and parsed a single
      // operand
      Expression parsedExp;
      if (operatorName.equals("sqrt"))
          parsedExp = new SqrtOperator(operands[0]);
      else if (operatorName.equals("abs"))
          parsedExp = new AbsOperator(operands[0]);
      else if (operatorName.equals("sin"))
          parsedExp = new SineOperator(operands[0]);
      else if (operatorName.equals("cos"))
          parsedExp = new CosineOperator(operands[0]);
      else if ...
   ⋮
}

We need some way to make it easier to modify and maintain this and similar bits of code in our program that deal with creation of objects of varying types.

3.1 The Prototype Pattern

The Prototype pattern offers one approach to resolving this problem. It stems from the fact that, although we cannot construct objects by dynamic binding, we can copy objects via dynamic binding.

So, if we have one or more prototype objects available that illustrate the different classes that we want to create one of, we can copy that prototype object instead of trying to invoke its constructor directly.

For example, in our spreadsheet, we might simply store one example of each single-operand operator in an array, and search for and copy the one we want:

final static Expression[] prototypes = {
   new SqrtOperator(null), new AbsOperator(null), 
   new SineOperator(null), new CosineOperator(null),
   ...
};

static public Expression parse(Expression e) {
    Expression[] operands;
    String operatorName = ...;
    ⋮
      // We have found the operatorName and parsed a single
      // operand
      Expression parsedExp = null;
      for (Expression proto: prototypes) {
          if (operatorName.equals(proto.getOperatorName())) {
             parsedExp = (Expression)proto.clone();
             parsedExp.setOperand (0, operands[0]);
           break;
          }
      }
   ⋮
}

This does not actually reduce the overall coupling of the parsing function, but it probably simplify the addition of new operator types to the program.

3.2 The Factory Pattern

I once worked on a project that processed PDF documents, occasionally needing to send selected pages to an OCR (Optical Character Recognition) program to extract the text of the page into character string form.

void processPage (PDFPage page) {
    ⋮
    OCR ocr = OCRFactor.getOCR();
    String extractedText = ocr.scanPage(page);
    ⋮
}

OCR programs can be expensive, and different customers of ours had already purchased different OCR programs and were not interested in buying another just to use with our software.

Our solution was to write a generic interface for doing OCR,

public interface OCR {
    // public static boolean isInstalled();
    public String scanPage (PDFPage page);
}

then write a class implementing that interface for each OCR program. That’s straightforward enough. But how did our program know which of those OCR classes it should use when the customer ran the code?

We added a class that checked to see whether the various OCR programs were installed on the machine, and returned an object of the appropriate class:

class OCRFactory {
    if (ACMEOCR.isInstalled())
        return new ACMEOCR();
    else if (SoftCorpOCR.isInstalled())
        return new SoftCorpOCR();
    else if ...
}

This is an example of the Factory pattern.

You can see that this pattern avoids coupling the application to the various concrete subclasses. The factory itself still needs to know about the concrete instances, but if creation of those objects occurs in many places in the application, this is still an overall simplification.

There are a number of variations on this pattern. In the Abstract Factory pattern, a variety of different factories are provided n their own inheritance hierarchy, each implementing a different strategy for selecting concrete classes.

• This can be used, for example, to provide one factory for choosing among Windows options, a separate factory for choosing Linux options, etc.

A variation that I find particularly useful is to add parameters to the createinstance function that help it to choose which instance to create. This is what I would do in our spreadsheet problem:

class ExpressionFactory {

    final private static Expression[] prototypes = {
       new PlusOperator(null,null), new SubtractOperator(null,null), 
       new TimesOperator(null,null), new DividesOperator(null,null), 
       new SqrtOperator(null), new AbsOperator(null), 
       new SineOperator(null), new CosineOperator(null),
       ⋮
    };

    public Expression createInstance (
        String operatorName,
        int nOperands) throws ParseError
    {
      for (Expression proto: prototypes) {
          if (operatorName.equals(proto.getOperatorName())
              && nOperands == proto.arity()) {
              return (Expression)proto.clone();
          }
      }
      throw new ParseError();
    }
 }
    ⋮
 static public Expression parse(Expression e) {
    ExpressionFactory factory = new ExpressionFactory();    
    Expression[] operands;
    String operatorName = ...;
    ⋮
      // We have found the operatorName and parsed a single
      // operand
      Expression parsedExp = factory.createInstance(operatorName, 1);
   ⋮
}

This moves all of the Expression-subclass coupling out of the Expression class, which

• is complicated enough already, and
• would be problematic since,
  • if Expression depends on its own subclasses
  • and, by definition, every subclass depends on its base class
  we wind up with a circular dependency. Circular dependencies are illegal C++, though technically legal in Java. Even when legal, they are considered a bad idea, and can break IDEs and build managers, as they have problems figuring out which classes need to be recompiled after changes are made.