TITLE: The open/closed principle


PROBLEM: djones@megatest.com (Dave Jones)

"Open/closed principle"  ... what is it, and who first buzzed the words?


RESPONSE: justin@logcam.co.uk (Justin Forder), 18 May 93

Bertrand Meyer, in "Object-oriented Software Construction", page 23:

"The Open-Closed Principle

A satisfactory modular decomposition technique must satisfy one more
requirement: it should yield modules that are _both_ open and closed.

- A module will be said to be open if it is still available for extension. 
  For example, it should be possible to add fields to the data structures
  it contains, or new elements to the set of functions it performs.

- A module will be said to be closed if it is available for use by other
  modules. This assumes that the module has been given a well-defined, 
  stable description (the interface in the sense of information hiding).
  In the case of a programming language module, a closed module is one 
  that may be compiled and stored in a library, for others to use.
  In the case of a design or specification module, closing a module
  simply means having it approved by management, adding it to the project's
  official repository of accepted software items (often called the project
  _baseline_), and publishing its interface for the benefit of other 
  module designers."

Meyer goes on to give an example, and to explain how the tension between
delivering stable items to their users, on the one hand, and maintaining
extensibility, on the other, gives real problems in classical development
approaches. With inheritance and polymorphism, a class can be closed (in
the sense that it is complete and delivers what its interface description
promises) and open (because you can specialise it). When new subclasses are
introduced, neither the original class nor its clients need to be edited or
recompiled.