DesignPrinciples

Decorator Pattern

I wanted to start the series out with the decorator pattern. It’s straightforward and helps maintain SOLID principles by allowing us to extend classes instead of modifying them. Definition The Decorator pattern allows behaviour to be added to an individual object, either statically or dynamically, without affecting the behaviour of other objects from the same class. It is used to: Enhance the functionality of an object at run-time by wrapping the object with additional behaviour. Add behaviour to an object without having to create a new derived class. Modify the behaviour of an object dynamically, while keeping the code maintainable and scalable. Let’s see it in action We start with our usual Animal base class

Wednesday, February 1, 2023 Read

Dependency Inversion Principle

The ‘D’ in SOLID design principles is for the Dependency Inversion Principle. The gist of it is about decoupling the dependency of high-level modules from low-level modules. So that any changes in low-level modules don’t affect the high-level modules. When I first started coding my high-level modules (user interfaces) would heavily depend on the low-level modules (databases). If I ever wanted to switch to a different database provider it would involve moving the database, as-is, to the new infrastructure, due to these dependencies. Making changes to the database structure would also reflect those changes in code.

Friday, January 20, 2023 Read

Interface Segregation Principle

The ‘I’ in SOLID design principles is for the Interface Segregation Principle. The gist of it is that clients should not be forced to implement interfaces they don’t use. In other words, create interfaces that serve the client’s needs, instead of creating one general-purpose interface that attempts to serve all possible clients. This promotes the use of smaller, more focused interfaces which can be easier to understand and implement. In keeping with our zoo example, pretend we’re building a management system which would help the zookeepers in their day-to-day jobs. We would need those working with mammals to feed and walk the animals but fish don’t need to go for walks.

Thursday, January 19, 2023 Read

Open-closed Principle

The ‘O’ in SOLID design principles is for the Open-Closed Principle. The gist of it is that any class or module should be open for extension but closed for modification. In other words, it should be possible to add new behaviour to a system without modifying its existing code. One of the key benefits of adhering to the open/closed principle is that it promotes the development of flexible and maintainable code. By following this principle, developers can create systems that are easy to modify and extend over time, without having to make changes to the underlying codebase.

Monday, January 16, 2023 Read

Single Responsibility Principle

The ‘S’ in SOLID design principles is for the Single Responsibility Principle. It is also the easiest one, in my opinion. The gist of it is that every part of the system should have only a single responsibility, including the system itself. Take the below code p { } u p { } p { } p { } b u / u / u / l b / b / b / i l l l c i L i L i L c o c o c o c g g g l i i i a o c o c o c s i i i s d g d g d g o o o U A e D e M e s c s e s a s e t l i r i h e h l h v e t e U e a r e r s r t e U e e e e s r U e ( s r ) e ( r ) ( ) On the surface, this looks fine, but those methods’ logic is neither reusable nor easily refactored.

Sunday, January 15, 2023 Read