The Open-Closed Principle

---

Software systems change over time. Change takes many forms, but changing and evolving system requirements provide the primary catalyst. A software system must accommodate change. It must evolve gracefully throughout its useful lifecycle. A software system that is rigid, fragile, and change-resistant exhibits bad design. A software system that is resilient, flexible, and extensible possesses the hallmark characteristics of thoughtful object-oriented architecture. The open-closed principle (OCP) provides the necessary framework for achieving an extensible and accommodating software architecture.

Formulated by Bertrand Meyer, the open-closed principle makes the following assertion:

Software modules must be designed and implemented in a manner that opens them for extension but closes them for modification.

Said another way, changes to software modules should be avoided and new system functionality added by writing new code.

It should be noted that writing code that is easy to extend and maintain is a requirement in and of itself. Writing such code takes longer initially but pays a big dividend later. I call it the design dividend.

Achieving The Open-Closed Principle

The key to writing code that conforms to the open-closed principle is to depend upon abstractions, not upon implementations. The reason - abstractions tend to be more stable. (Correctly designed abstractions are very stable!) This is achieved in C++ through the use of abstract base classes and dynamic polymorphic behavior. Code should rely only upon the interface functions and behavior promised via abstract base class interfaces. A code module that relies only upon abstractions will exhibit the characteristic of being closed to the need for modification yet open to the possibility of extension.

An OCP Example

A good example of code written with the OCP in mind is the fleet simulation model originally discussed and presented in chapter 13. Figure 19-9 gives the UML class diagram showing the static relationship between the classes that comprise the fleet simulation model.

Figure 19-9: Fleet Simulation Model Class Diagram

The model foundation consists of three core abstractions: Vessel, Weapon, and Plant. A Vessel is comprised of a Plant and a Weapon. Vessel depends only upon these abstractions and is therefore closed to modification. Weapon depends on nothing as does Plant.

Plant and Weapon can be extended as necessary to create new power plant and weapon system types. Vessel cares not about the new types, so long as the new types abide by the LSP and DbC and provide the behavior promised by the abstractions they extend.

Vessel itself can be extended to create new vessel types. A new vessel type still depends only upon the Weapon and Plant abstractions, and of course upon the Vessel class it extends.

Additional OCP Conventions

There are also a few other conventions the fleet simulation code abides by that brings it further in line with the OCP. All member attributes are kept private, there are no global variables, and the Runtime Type Identification (RTTI) mechanism is not used to determine what types are being dealt with in the code.

Relationship Between the OCP and the LSP/DbC

The OCP and LSP/DbC share a close relationship. Code written with the OCP in mind depends upon behavior promised by abstract base class specification. Depending upon promised behavior enables the subtype reasoning process. The LSP/DbC is used to achieve the proper subtype behavior within a type hierarchy thereby enabling the OCP.

Quick Review

The open-closed principle (OCP) attempts to optimize object-oriented software architecture design so it can accommodate change. Software modules should be designed so they are closed to modification yet open to extension. The OCP is achieved by depending only upon software abstractions. In C++ this means designing with abstract base classes with the goal of dynamic polymorphic behavior. The OCP relies heavily upon the Liskov substitution principle and design by contract (LSP/DbC).

---