SOLID Principles

Turning ideas into reality through software is a logical art form that must be done with great care. Building sophisticated software is fun and challenging, but maintaining and updating poorly written software is even more difficult and frustrating. The methodology for writing good, well-structured code is to follow and adhere to a set of principles known as the SOLID Principles.

The SOLID principle was developed by computer scientist Robert J. Martin in an article published in 2000. Since then, SOLID principles have been widely adopted and are considered the basis for good software design. Consider the abbreviation SOLID.

(E) Principle of Sole Liability

A class can serve only one purpose. That is, a class can perform only one type of operation, such as database logic, logging logic, and so on. This principle ensures that each class focuses on a single responsibility and does not burden the code with extra work that makes it difficult to modify or maintain. For example, consider a class responsible for recording and processing data. This violates the single responsibility principle because the class has two responsibilities. I recommend creating two separate classes, one for logging and one for handling data, each with its own responsibilities.

(O) pen/closing principle

Classes should be open for extension and closed for modification. That is, existing classes must be extensible without having to be rewritten to implement new functionality. This principle promotes the use of abstractions that enable flexible, modular code that can be extended without changing existing code.

For example, let's take a class that generates a report. Instead of modifying the existing class whenever a new report type is added, it is recommended that you create a new class that inherits from the original report class and adds new functionality.

(L)iskov's substitution principle

It should be easy to replace parent classes with child classes. That is, if the Rectangle class is a subtype of the Shape class, Shape can be replaced by Rectangle without breaking the functional flow. This principle promotes the use of inheritance in a way that preserves system functionality.

For example, consider a class hierarchy where the base class is Image and the derived classes are Rectangle and Circle. The Liskow substitution principle should allow code to use any expected shape, such as a rectangle or a circle, without causing problems.

(I) Principle of interfacial separation

Interfaces should not force classes to implement functionality they do not support. This means that larger interfaces must be split into smaller interfaces to provide support. This principle promotes the use of small, focused interfaces specific to the requirements of each class.

For example, take an interface with 10 methods. If a class needs to implement only two of these methods, consider splitting the interface into two sub-interfaces, each containing only the necessary methods.

(D) Principle of inversion of dependence

Classes should depend on abstractions, but not specifications. That is, higher-level modules should not depend on lower-level modules. Both must be based on abstraction. This principle uses interfaces to separate classes and promotes modular design. For example, consider a class that depends on a database. Instead of using the database classes directly, it is recommended to create an interface with the database and make the classes depend on the interface. This promotes loose coupling and enables flexible code.

Finally, the SOLID principles provide guidelines for writing maintainable and extensible software. Following these principles helps software engineers create code that is easier to understand, adapt, and maintain over time. By applying these principles, software engineers can create high-quality software.