In 1987, Barbara Liskov stated the following:
“If S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of the program.”
That’s a mouthful. Let’s break it down into plain English.
InPost just changed their pricing model. Again. You open ShippingCalculator, find the switch statement, locate the InPost branch, and carefully edit the formula. While you’re in there, you notice the DHL branch looks suspicious too. You touch it. Now two things are broken instead of one.
This is the cost of code that is never finished being modified. The Open/Closed Principle offers a different approach: write code that you add to, not code that you keep rewriting.
A new security requirement arrives: passwords must be hashed with bcrypt instead of MD5. Simple enough. You open the User class to make the change and find yourself scrolling past email-sending logic, database queries, and input validation before you even get to the hashing method. You make the change, run the tests, and three unrelated things break.
This is what happens when a class has too many reasons to change. The Single Responsibility Principle exists to prevent exactly this: one class, one job, one reason to be touched.
Design Patterns Series #3 – Creational Patterns The feature request seemed simple: “We’re adding drone delivery next quarter.” You opened the order processing class, found…