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.
Latest Posts
Open/Closed Principle: Add, Don’t Rewrite
Single Responsibility Principle: One Class, One Job
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.
Factory Method: Stop Scattering new Across Your Business Logic
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…
Builder Pattern: Stop Counting Commas
How many parameters is too many? Four? Six? There’s a constructor somewhere in every codebase that crossed the line, the one where you have to count commas to figure out which argument goes where, and where passing null for “optional” fields became completely normal.