Open-Closed Principle

Extension and Modification

Open for extension means that when requirements of the application change, we can extend the module with new behaviors that reflect those changes. We change what the module does.

Closed for modification means that changes in behavior do not result in changes in the module's source or binary code.

Several reasons for closing modules against changes:

• The module was delivered to customers and a change will not be accepted. If you need to change something later, hopefully you opened your module for extension!
• The module is a third-party Library/Framework and only available as binary code. If you need to change something, hopefully the third-party opened the module for extension!
• Most importantly: not changing existing code means modular compilation, testing and debugging.

Abstraction is the Key

Different kinds of abstraction mechanisms exist:

• Object-oriented languages:

  • abstractions are encoded in abstract base classes resp. interfaces.
  • unbounded group of possible behaviors is represented by all the possible derivative classes resp. implementations.

• Functional languages:

  • abstractions are encoded in function types.
  • unbounded group of possible behaviors is represented by all the possible first-class functions of the declared type.

In the following, we shortly discuss the two main ways of abstracting over variability in object-oriented programs.

• Container declares the layout functionality but does not implement it. The rest of Container is implemented against the abstraction.
• Concrete subclasses fill in the details over which Container’s implementation abstract.

• Container delegates the layout functionality to an abstraction. The rest of its functionality is implemented against this abstraction.
• To change the behavior of an instance of Container we configure it with the LayoutManager of our choice.
• We can add completely new behavior by implementing our own LayoutManager.

Understanding the Open-Closed Principle

• Each Shape identifies itself via the enumeration ShapeType.
• Realizations of Shape declare specialized methods for the shape type they represent.

class Application {
  public void drawAllShapes(List<Shape> shapes) {
    for(Shape shape : shapes) {
      switch(shape.getType()) {
      case Circle:
        drawCircle((Circle)shape);
        break;
      case Rectangle:
        drawRectangle((Rectangle)shape);
        break;
  } } }

  private void drawCircle(Circle circle) { ... }

  private void drawRectangle(Rectangle rectangle) { ... }
}

Evaluating the proposed design:

• Adding new shapes is hard, we need to:

  • Implement a new realization of Shape.
  • Add a new member to ShapeType.
    This possibly leads to a recompile of all other realizations of Shape.
  • drawAllShapes (and every method that uses shapes of different types) must be changed.
    We have to hunt for every place that contains conditional logic that distinguishes between types of shapes and we have to add code to it.
• drawAllShapes is hard to reuse!
  When we reuse it, we have to bring along Rectangle and Circle.

Assessing our design w.r.t. its rigidity, fragility and immobility:

• Our example design is rigid: Adding a new shape causes many existing classes to be changed.
• Our example design is fragile: Many switch/case (if/else) statements that are both hard to find and hard to decipher.
• Our example design is immobile: drawAllShapes is hard to reuse.

• Makes adding new shapes possible without modification.
  We just need to implement a new realization of Shape.

• drawAllShapes only depends on Shape.
  We can reuse it unchanged.

This unconditional statement is – of course – not correct. It is not possible to be open for all kinds of extension and also be closed for modification.

• Consider extending the design with further shape functions:

  • shape transformations, shape dragging, …
  • calculating the intersection or union of shapes, etc.
• Consider adding support for different operating systems.
  The implementation of the drawing functionality varies for different operating systems.

• Change is easy if change units correspond to abstraction units.
  In our example, adding a new type of Shape is easy as it is directly supported by inheritance and subtyping.
• Change is tedious if change units do not correspond to abstraction units.

Abstractions Reflect a Viewpoint

When we consider the classes Oviparous and Mammal it is obvious that the class hierarchy reflects the veterinary surgeon's understanding.

• Elements of a category in one model correspond to several categories in the other model (and vice versa).
• Adopting the veterinary viewpoint hinders changes concerning trainer’s viewpoint (and vice versa).

Using a programming language which offers more advanced modeling mechanisms, it may be possible to create a design that more closely models the presented world.

Strategic and Agile Closure