Thoughts: Open-Closed Principle

Just read an article about Open Closed Principle[pdf]. It is good revision and insight into object oriented principles.

Very briefly, Open Closed Principle says to design your class which are close for modification and open for extension. As author suggests one way of doing this is to program to interfaces. So that the classes in design are closed for modification and open for extension.
How to ensure that the class designed is closed for modification? Though author points out that you can't close the class entirely. What is the generic questions checklist that we need to go through to verify that the class is closed for modification.

• Is the class close for modification due to change in business requirements?
  Business requirements change over time. The question we need to ask while reviewing the design is that have we designed the class in manner that it is able to display some flexibility of handling the changed requirement by extending it and not by modifying it. Are the safeguards in place which prevents changing the classes?
  


• Will the changes in classes on which this class depends bring change in this class?
  List down all classes which are used by the class under review. All the objects which are part of pre-condition for this class to operate.
  Determine that how close is the current class' design in order to accomodate changes in these classes.
  Key question: Are the contract between these classes defined by interfaces? (This leads to another principle of Dependancy Inversion Principle[pdf])
  


• Will the changes in the classes which depends on this class bring change in this class?
  List down all the classes which will use the current class.
  Determine that how close is the current class' design in order to service the changing demands of these classes/objects.
  Key question: Is Contract between these classes defined by interfaces?
  


• Has design considered multiplicity requirements?
  Lets say that sound contract exists between the classes on which the class depends and the classes which depends on this particular class.
  Determine the impact of change in cardinality requirement of contract. A class may play different role. Does this class play role of "creator" of objects, "worker" on objects and/or "delegator" to objects. The contract defined in interface does it cover scenarios like: what if this class needs to "create" more than one objects in future. Is this class close enough for modification and open enough for extension to allow to "work" on multiple objects.
  

Again I think all this questions needs to be asked keeping in mind the domain for which it is getting designed. This questions are subjective to functional area application is trying to solve.