Object Oriented Programming

The Critical Role of Interface Design in Future-Proofing Software Development

Imagine living in a house where your toaster, blender, and coffee maker are hardwired into the walls. Now consider the hassle you’d face when an upgraded appliance hits the market, or when your current device wears out. It sounds inconvenient, right? Thankfully, in our homes, we have standardized electrical sockets – a universal interface that… Read more The Critical Role of Interface Design in Future-Proofing Software Development

How SOLID is the STRATEGY PATTERN?

STRATEGY PATTERN In a strategy pattern the main value is in being able to switch out different algorithms for different situations. Imagine that you had an application component that renders graphs for a website depending on what kind of device made the request. The application code could detect the type of browser and then use… Read more How SOLID is the STRATEGY PATTERN?

SOLID OOP, Liskov Substitution Principle

Liskov Substitution Principle The Liskov Substitution Principle [1] (LSP) is applied to inheritance hierarchies. LSP specifies that classes should be designed such that client dependencies can be substituted with subclasses without the client “knowing”. How to apply the Liskov Substitution Principle To adhere to Liskov Substitution Principle, subclasses must function in the same way as… Read more SOLID OOP, Liskov Substitution Principle

SOLID OOP, OPEN/CLOSE PRINCIPLE (OCP)

Open/Close Principle (OCP) The Open/Close Principle means that software entities should be open for extension but closed for modification [1]. Open to extension “Open to extension” means that classes are designed with the possibility of new functionality in mind. Down the road, one can extend functionality as new requirements come up. Closed for modification “Closed… Read more SOLID OOP, OPEN/CLOSE PRINCIPLE (OCP)

SOLID OOP, Single Responsibility Principle

Single Responsibility Principle (SRP): Single responsibility principle [1] means that any one class should not have more than one reason to change. For this to be true, a class will only have one single responsibility. Avoid creating a god class [2]. Objects that are controlling way too many other objects in a system and often… Read more SOLID OOP, Single Responsibility Principle