It’s been raining all week in Sarasota, Florida and all day long today. Perfect weather for playing inside with the kids, watching movies I would never normally watch, and sipping on green tea while reading a good book, Agile Software Development Principles, Patterns, and Practices, by Robert C. Martin (Amazon).
I have completed 9 chapters of this 30 chapter book and have enjoyed it tremendously. So far, I would highly recommend it for someone interested in reading about solid OOP principles and guidelines for developing software. I enjoy reading these good practices from a number of different books with different styles and examples because it helps reinforce the information as well as perhaps opens new insights.
Here are the chapters I have read so far:
- Chapter 1 – 4: Agile Practices, Extreme Programming, and Test-Driven Development
- Chapter 5 and 6: Refactoring and Pair Programming
- Chapter 7: Agile Design
- Chapter 8: Single-Responsibility Principle
Chapter 9 is on the Open-Closed Principle:
The author goes on to explain that this principle encourages the developer to refactor (MSDN Refactoring Webcast) the software such that if enhancements or changes are required at a later time, it only requires the developer to add new code, not change exisiting code. This is a rather cool idea, because it means that maintaing software in the future should be easier as you don’t have to worry as much about breaking existing code. Forgetting for a moment whether this notion is realistic or even achievable, it is a good thing to shoot for in your applications.
Robert Martin says modules that adhere to this Open-Closed Principle have 2 primary attributes:
- “Open For Extension” – It is possible to extend the behavior of the module as the requirements of the application change (i.e. change the behavior of the module).
- “Closed For Modification” – Extending the behavior of the module does not result in the changing of the source code or binary code of the module itself.
At first glance, these two attributes seem to be at odds. However, as I read further through the chapter, I realize he is referring to using Abstract Classes and their Concrete SubClasses to extend behavior. This essentially means using something like the Template Method Pattern or Strategy Pattern to delegate either part or all of an algorithm in a Concrete SubClass. The Template Method Pattern UML is shown below:
A Template Method is a Method in an (abstract) base class which calls one or more HookMethods to fulfill parts of its tasks. You can easily extend or change the behavior of the abstract base class by creating new subclasses that implement a new version of the Hook Method. This fulfills the requirements of the Open-Closed Principle.
Every good application is probably teeming with abstract base classes for this very thing, and I know of 3 open-source applications I have recently talked about where you can find it:
- DotNetNuke – Provider model for the data access layer
- Community Server – Provider model for the data access layer
- Enterprise Library – Used in every application block to add new functionality.
Each of the open-source applications use modules supporting the Open-Closed Principle to allow them to plug either 1) a new data provider in the case of DotNetNuke and Community Server, or 2) a new caching strategy (as an example) for the Enterprise Library. This extensability is achieved using a pluggable architecture that uses reflection and configuration files, which is one way to achieve the “Open For Extension” but “Closed For Modifications” idea of the Open-Closed Principle.