SOLID

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.

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.

Thursday, January 19, 2023 Read

Liskov's Substitution Principle

The ‘L’ in SOLID design principles is for Liskov’s Substitution Principle. The gist of it is that objects of a superclass should be able to be replaced with objects of a subclass without altering the correctness of the program. In keeping with our zoo program, if we have a Bird class with a Fly() method, what happens to flightless birds? According to the LSP, if a program is written with a list of “Bird” objects and a “Penguin” object is added to the list, the program should still work correctly without any modification.

Tuesday, January 17, 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.

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 public class User { public void ActivateUser() { // Logic goes here } public void DeleteUser() { // Logic goes here } public void MailUser() { // Logic goes here } } On the surface, this looks fine, but those methods’ logic is neither reusable nor easily refactored.

Sunday, January 15, 2023 Read