Dependency Inversion Principle
Depend on Abstractions, Not on Concrete Implementations The Dependency Inversion Principle (DIP), the fifth and final principle of SOLID, states that: “High-level modules should not[…]
Interface Segregation Principle
Many Small Interfaces Instead of One Large Interface The Interface Segregation Principle (ISP) states that no class should be forced to implement methods that it[…]
Liskov Substitution Principle
A Subclass Must Be a Replaceable Substitute for Its Base Class The Liskov Substitution Principle (LSP) states that objects of a derived class should be[…]
Open/Closed Principle
Open for Extension, Closed for Modification Definition The Open/Closed Principle (OCP) states that software entities (such as classes, modules, or functions) should be open for[…]
Single Responsibility Principle
One Class — One Reason to Change The Single Responsibility Principle (SRP) states that a class should have only one reason to change. “A class[…]
Strategy – When Behavior Needs to Be Flexible
In many applications, you don’t just create objects — you also need to define how they behave. And that behavior can change. Discount calculation, payment[…]
Factory – When new Becomes a Problem
When you start coding, creating objects is simple: Product product = new Product(); But as your application grows, object creation often becomes… messy. At some[…]
Builder – When a Constructor Is Not Enough
Imagine you need to create an object with a dozen fields — some required, some optional, some dependent on each other, and some that must[…]