I am trying to understand the SOLID principles of OOP and I've come to the conclusion that LSP and OCP have some similarities (if not to say more).
the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification".
LSP in simple words states that any instance of Foo
can be replaced with any instance of Bar
which is derived from Foo
and the program will work the same very way.
I'm not a pro OOP programmer, but it seems to me that LSP is only possible if Bar
, derived from Foo
does not change anything in it but only extends it. That means that in particular program LSP is true only when OCP is true and OCP is true only if LSP is true. That means that they are equal.
Correct me if I'm wrong. I really want to understand these ideas.
Great thanks for an answer.
Best Answer
Gosh, there are some weird misconceptions on what OCP and LSP and some are due to mismatch of some terminologies and confusing examples. Both principles are only the "same thing" if you implement them the same way. Patterns usually follow the principles in one way or another with few exceptions.
The differences will be explained further down but first let us take a dive into the principles themselves:
Open-Closed Principle (OCP)
According to Uncle Bob:
Note that the word extend in this case doesn't necessarily mean that you should subclass the actual class that needs the new behavior. See how I mentioned at first mismatch of terminology? The keyword
extend
only means subclassing in Java, but the principles are older than Java.The original came from Bertrand Meyer in 1988:
Here it is much clearer that the principle is applied to software entities. A bad example would be override the software entity as you're modifying the code completely instead of providing some point of extension. The behavior of the software entity itself should be extensible and a good example of this is implementation of the Strategy-pattern (because it is the easiest to show of the GoF-patterns bunch IMHO):
In the example above the
Context
is locked for further modifications. Most programmers would probably want to subclass the class in order to extend it but here we don't because it assumes it's behavior can be changed through anything that implements theIBehavior
interface.I.e. the context class is closed for modification but open for extension. It actually follows another basic principle because we're putting the behavior with object composition instead of inheritance:
I'll let the reader read up on that principle as it is outside the scope of this question. To continue with the example, say we have the following implementations of the IBehavior interface:
Using this pattern we can modify the behavior of the context at runtime, through the
setBehavior
method as extension point.So whenever you want to extend the "closed" context class, do it by subclassing it's "open" collaborating dependency. This is clearly not the same thing as subclassing the context itself yet it is OCP. LSP makes no mention about this either.
Extending with Mixins Instead of Inheritance
There are other ways to do OCP other than subclassing. One way is to keep your classes open for extension through the use of mixins. This is useful e.g. in languages that are prototype-based rather than class-based. The idea is to amend a dynamic object with more methods or attributes as needed, in other words objects that blends or "mixes in" with other objects.
Here is a javascript example of a mixin that renders a simple HTML template for anchors:
The idea is to extend the objects dynamically and the advantage of this is that objects may share methods even if they are in completely different domains. In the above case you can easily create other kinds of html anchors by extending your specific implementation with the
LinkMixin
.In terms of OCP, the "mixins" are extensions. In the example above the
YoutubeLink
is our software entity that is closed for modification, but open for extensions through the use of mixins. The object hierarchy is flattened out which makes it impossible to check for types. However this is not really a bad thing, and I'll explain in further down that checking for types is generally a bad idea and breaks the idea with polymorphism.Note that it is possible to do multiple inheritance with this method as most
extend
implementations can mix-in multiple objects:The only thing you need to keep in mind is to not collide the names, i.e. mixins happen to define the same name of some attributes or methods as they will be overridden. In my humble experience this is a non-issue and if it does happen it is an indication of flawed design.
Liskov's Substitution Principle (LSP)
Uncle Bob defines it simply by:
This principle is old, in fact Uncle Bob's definition doesn't differentiate the principles as that makes LSP still closely related to OCP by the fact that, in the above Strategy example, the same supertype is used (
IBehavior
). So lets look at it's original definition by Barbara Liskov and see if we can find out something else about this principle that looks like a mathematical theorem:Lets shrug on this for a while, notice as it doesn't mention classes at all. In JavaScript you can actually follow LSP even though it is not explicitly class-based. If your program has a list of at least a couple of JavaScript objects that:
...then the objects are regarded as having the same "type" and it doesn't really matter for the program. This is essentially polymorphism. In generic sense; you shouldn't need to know the actual subtype if you're using it's interface. OCP does not say anything explicit about this. It also actually pinpoints a design mistake most novice programmers do:
Whenever you're feeling the urge to check the subtype of an object, you're most likely doing it WRONG.
Okay, so it might not be wrong all the time but if you have the urge to do some type checking with
instanceof
or enums, you might be doing the program a bit more convoluted for yourself than it needs to be. But this is not always the case; quick and dirty hacks to get things working is an okay concession to make in my mind if the solution is small enough, and if you practice merciless refactoring, it may get improved once changes demand it.There are ways around this "design mistake", depending on the actual problem:
Both of these are common code design "mistakes". There are a couple of different refactorings you can do, such as pull-up method, or refactor to a pattern such the Visitor pattern.
I actually like the Visitor pattern a lot as it can take care of large if-statement spaghetti and it is simpler to implement than what you'd think on existing code. Say we have the following context:
The outcomes of the if-statement can be translated into their own visitors as each is depending on some decision and some code to run. We can extract these like this:
At this point, if the programmer did not know about the Visitor pattern, he'd instead implement the Context class to check if it is of some certain type. Because the Visitor classes have a boolean
canDo
method, the implementor can use that method call to determine if it is the right object to do the job. The context class can use all visitors (and add new ones) like this:Both patterns follow OCP and LSP, however they are both pinpointing different things about them. So how does code look like if it violates one of the principles?
Violating one principle but following the other
There are ways to break one of the principles but still have the other be followed. The examples below seem contrived, for good reason, but I've actually seen these popping up in production code (and even worser):
Follows OCP but not LSP
Lets say we have the given code:
This piece of code follows the open-closed principle. If we're calling the context's
GetPersons
method, we'll get a bunch of persons all with their own implementations. That means that IPerson is closed for modification, but open for extension. However things take a dark turn when we have to use it:You have to do type checking and type conversion! Remember how I mentioned above how type checking is a bad thing? Oh no! But fear not, as also mentioned above either do some pull-up refactoring or implement a Visitor pattern. In this case we can simply do a pull up refactoring after adding a general method:
The benefit now is that you don't need to know the exact type anymore, following LSP:
Follows LSP but not OCP
Lets look at some code that follows LSP but not OCP, it is kind of contrived but bear with me on this one it's very subtle mistake:
The code does LSP because the context can use LiskovBase without knowing the actual type. You'd think this code follows OCP as well but look closely, is the class really closed? What if the
doStuff
method did more than just print out a line?The answer if it follows OCP is simply: NO, it isn't because in this object design we're required to override the code completely with something else. This opens up the cut-and-paste can of worms as you have to copy code over from the base class to get things working. The
doStuff
method sure is open for extension, but it wasn't completely closed for modification.We can apply the Template method pattern on this. The template method pattern is so common in frameworks that you might have been using it without knowing it (e.g. java swing components, c# forms and components, etc.). Here is that one way to close the
doStuff
method for modification and making sure it stays closed by marking it with java'sfinal
keyword. That keyword prevents anyone from subclassing the class further (in C# you can usesealed
to do the same thing).This example follows OCP and seems silly, which it is, but imagine this scaled up with more code to handle. I keep seeing code deployed in production where subclasses completely override everything and the overridden code is mostly cut-n-pasted between implementations. It works, but as with all code duplication is also a set-up for maintenance nightmares.
Conclusion
I hope this all clears out some questions regarding OCP and LSP and the differences/similarities between them. It is easy to dismiss them as the same but the examples above should show that they aren't.
Do note that, gathering from above sample code:
OCP is about locking the working code down but still keep it open somehow with some kind of extension points.
This is to avoid code duplication by encapsulating the code that changes as with the example of Template Method pattern. It also allows for failing fast as breaking changes are painful (i.e. change one place, break it everywhere else). For the sake of maintenance the concept of encapsulating change is a good thing, because changes always happen.
LSP is about letting the user handle different objects that implement a supertype without checking what the actual type they are. This is inherently what polymorphism is about.
This principle provides an alternative to do type-checking and type-conversion, that can get out of hand as the number of types grow, and can be achieved through pull-up refactoring or applying patterns such as Visitor.