Open for extension, closed for modification. The open-closed principle is on the of the great object oriented design principles of our time. Its a design principle that is very fragile where the smallest of changes can easily undo the closed-ness of a system. So, l’ll to summarise the principle for the purposes of our discussion, and to allow me to make some assertions on the validity of the principle for Enterprise Business Systems.

The open/closed principle states “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” [Meyer, Bertrand (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0136290493]. In principle, each software entity can allow it’s behaviour to be changed without the alteration to it’s source code.

So, l’ll start by giving an example of a successful outcome for the Open-Closed principle. My last project required the extension of Spring to enable some extra behavior during bean factory construction. So, we hunted and found the Spring class that implemented the XML file parsing and decided to extend the functionality. It was really simple, NewSpringClass extends SpringClass, then add the new behavior. Done! I did not need to download, modify then build the Spring code to add the new behavior. The Spring classes were implemented in a way that allowed for simple extension, otherwise we could have found ourselves doing things that we should be banished for doing.

Now, lets look at another modification scenario; changing business requirements. As new business requirements become known, we need to add new or modify old behavior of the system. How often is this done by extending the functionality of a system classes instead of modifying them? Well, thinking back, extension is rarely done, it’s mostly modification.

For example, when the business want the behavior of the system to debit accounts in a scenario instead of crediting the account, this will most definitely result in a modification. Does this mean that l’ve not implemented by Enterprise System correctly? Fortunately enough, this is not the case. I’ve used most of the good design practices like keeping my concerns separated, ensuring that my layers are well defined, designed my service interfaces at the correct granularity, avoided anti-patterns, etcetera. So, why is it that my changes to the Enterprise System is mostly modification?

The answer is the rate of change of the system during a standard development process. Behavior and functionality of a framework like Spring can be defined priori, where the changes of system requirements is significantly smaller than the change expected from Enterprise Systems. So, the Open-Closed principle breaks down when the requirements of a system are unpredictable. That’s the definitive point.

So, given l have demonstrated that the rate-of-change of Enterprise Business Systems has the propensity to force the Open-Closed principle out the door, what other options do we have in this architectural domain?  I believe that there are many; although the answers may not be in other patterns or principles.  All solutions in this domain need to be carefully considered where options of each solution carefully weighed-up, prioritised and recorded.  Applying a pragmatic view will always present a viable, well thought out solution.