To understand the developers’ intentions, we must look at an important principle of
object-oriented design entitled the Open-Closed Principle. Quoting Bob Martin,^1 as he
paraphrases Bertrand Meyer,^2 this principle is defined as follows:
Software entities (classes, modules, functions, etc.) should be open for extension, but
closed for modification.In other words, this principle states that a class should protect itself from alteration while
at the same time providing well-defined extension points. At first glance, these two objectives
seem contradictory, for isn’t implementing an extension point just another way to alter a class?
Good object-oriented design places a high premium on encapsulation, which is the hid-
ing of both data and implementation details. This principle states that a class should protect
itself from not only outside influence (something we are very familiar with, as we mark any
method as private), but also internal influence. Internal influence can be anything that might
have intimate knowledge of the class structure, such as subclasses (which are in a much more
powerful position to modify the behavior of a class). A well-designed class conforming to the
Open-Closed Principle considers even subclasses as potentially harmful, which is why you
will see so many methods marked as final.
So what type of harm is the class protecting itself from? Without the finalmodifier, a sub-
class is able to re-implement any non-private method of its superclass. This method overriding
is potentially very dangerous, as it might ignore or change the original implementation’s intents.
Any redefinition of a method would effectively break the contract the superclass has with the
rest of the system, leading to potentially unintended consequences.
But I hear you saying that your overriding method can simply call super.doMethod(),
ensuring that the original method’s logic is run (thus preserving the original method defini-
tion). This is the crux of the problem, as there is no way to force an overriding method to call
super.doMethod(). Also, does the subclass call the method before or after the overriding
method’s code? For libraries intended to be used across many different systems, this type of
uncertainly is not acceptable.
However, libraries intended for wide use must allow for customization, and this is where
“open for extension” comes in. Instead of allowing a class’s behavior to change, you should
allow a class to be extended. Extension happens via well-defined life cycle callback methods
(typically with method names such as onXxx()in the Spring Framework). These callback
methods are intended to be overridden, because they don’t define the core business logic of
the class. While the core business logic method is marked as final, it might call one or more
extension methods allowing a subclass to addin extra behavior.
To illustrate this principle in action, we will look at the high-level implementation of the
Controllerinterface, which is the org.springframework.web.servlet.mvc.AbstractController.
This first class in the Controllerhierarchy remains fairly simple. However, it provides the first
good example of the Open-Closed Principle in action, plus it gives us a good starting point to
examine the Controlleroptions.
CHAPTER 6 ■THE CONTROLLER MENAGERIE 117- Bob Martin, The Open-Closed Principle, http://www.objectmentor.com/resources/articles/ocp.pdf, 1996.
- Bertrand Meyer, Object Oriented Software Construction(Upper Saddle River, NJ: Prentice Hall, 1988) p 23.