As is the case with many developers, designers and architects, I've worked with many firms and many development teams, in many different roles. The teams that were successful were typically the teams that espoused many basic principles and executed those principles.
The Open-Closed Principle is one of the principles that contributed to the success of many of those projects that were successful.
Bertrand Meyer originated this principle by stating: A class should be open for extension, but closed for modification.
Now many designers and developers practice this without knowing that it has an official name. Congratulations if you are among them. If not, take the time to understand this principle. Let's review.
The second clause of this statement is the easier of the two clauses, so let's start with "but closed for modification".
Simply stated, no existing code for an existing class in an existing application should be modified in any way. Great, I think we can stop there. This sounds like crazy talk. Don't change anything that's deployed?
The reality is, a class as originally deployed had responsibilities to the application as defined by its coupling and cohesion. If a modification is made to a class, the behavior of the application may then exhibit undesirable results (ok, BUGS). In an effort to minimize this effect, the class should remain closed to modification.
"A class should be open for extension"
This statement is a bit more complex. That complexity originates from the usage of the word "open". Extending a class as a discipline seems like it should be an easy task and many times that may actually be the case. If the class is open, it will provide for easy subclassing and overriding in the methods. Other examples of the practice of extending a class relate to the use of structural design patterns such as the decorator or behavioral design patterns such as the visitor. The key in all of these practices is abstraction, but I think that that is a topic of discussion unto itself.
There are many difficulties in these practices of extensions of classes. In upcoming posts, I'll discuss some of the principles which help to extend classes without ineptly, inadvertently or otherwise, damage the class hierarchy or the expected behavior of software systems.
The Agile Developer recently did a fantastic presentation at the May Wisconsin Ineta Users Group Meeting. As a practitioner of patterns in my everyday work and as a colleague of his at the time, I watched first-hand as he put the presentation together. So it occurred to me: Most developers and designers use patterns in their everyday activities, but may be unaware of it. Furthermore, if someone is unaware of a pattern, it may be difficult to tell them the story of the pattern. In a conversation with Gerry on the phone the other day (while we were both driving), we discussed the mediator pattern. Now this is a very simple pattern, with its primary reason for living being the de-coupling of objects. But I couldn't come up with a simple story to demonstrate this fact. So, I think to some extent, patterns are like Number Theory; they are easy to discuss, but difficult to explain (actually in Number Theory, problems are "easy to state, difficult to solve"). The following resources below will help to provide directions in learning patterns if you are a beginner. I'll try to provide primers on patterns as time permits.
Books to own (not a comprehensive list, but rather a useful start for a collection):
- Design Patterns: Elements of Reusable Object Oriented Software. Gamma, Helms, Johnson and Vlissides (Gang of Four or GoF) (1994). The original design patterns book. A must own if you are serious about patterns.
- Analysis Patterns - Fowler (1997). An outstanding work that reinforced (way back then) that vertical patterns in software were practical and useful. Interestingly, my first read of this book found me recognizing most of the patterns in the book as I had practiced them.
- Patterns of Enterprise Application Architecture - Fowler (2003). Mr. Fowler provides a thorough and understandable treatment of patterns of organization in software that are applicable for the enterprise.
- Enterprise Integration Patterns - Hohpe and Woolf (2003). The book that finally gives the basic patterns for messaging application designs. Included here are clear expositions on many of the patterns that are required for Web Services and other Service Oriented work.
- Refactoring to Patterns - Kerievsky (2004/5). The first book to attack as a discipline, the refactoring of code to the GoF Design Patterns. I'll have a formal book review on this shortly.
Sites to visit (in no particular order):
- The Agile Developer - This developer just started with ThoughtWorks and as mentioned above presented on Design Patterns in May.
- Head First Design Patterns In CSharp (zip file) - Local C# MVP Sean, pointed to this set of examples recently.
- Martin Fowler - Martin Fowler's site for patterns and other software disciplines.
- Hillside - A community of patterns practitioners (I believe this was started by Ralph Johnson from GoF). This site has as members, the people responsible for patterns in software as we now know it.
- Pattern Share - A centralized catalog of patterns of any classification from most of the major sources in this domain.
- Data and Object Factory - Site the provides some of the basics on GoF patterns with codes samples here.
- Kerievsky - This site contains much of the work that Mr. Kerievsky espouses in his book (see above). For beginners, this is useful.
- Cunningham's Wiki - Ward Cunningham's site for patterns and other software disciplines.
If you've advanced and know all of the GoF patterns (including the patterns informally voted off of the island at OOPSLA 2004), all of the Fowler EAA patterns, Hohpe and Woolf's EIS patterns, the entire catalog at Pattern Share, or if you PLoP, spread the word and teach your colleagues. I'll try to provide specific examples of where the application of "the right" pattern can lead to difficulties, e.g. the use of the strategy pattern in the face of a significant cartesian product in either the strategies or the data. Please also review my List of GP Projects (specifically #3) for some upcoming work on patterns.
I noticed Boris mentioned the zoo.
If you are a Theory of Computation person (or want to be) and think that the classification of these problems is interesting, visit the zoo and see all of the animals.
The most popular complexity classes are P and NP (as if this was a popularity contest). Get a copy of Garey and Johnson’s "Computers and Intractability: A Guide to the Theory of NP-Completeness" to get a background on this subject. Sipser and Papadimitriou are other authors that have great starter books on the topic.