SOLID is a set of five design principles that helps developers write maintainable, extendable and understandable software. Popularized by Robert C. Martin, it stands for these principles: Single Responsibility Principle (S), Open/Close Principle (O), Liskov Substitution Principle (L), Interface Segregation Principle (I) and Dependency Inversion Principle (D). To make them easier to understand and remember for everyone, not only for technical people, I will compare them through everyday examples as well as software development contexts.
Single Responsibility Principle, which is the first one in SOLID, simply means a module should perform only one task and perform it well. In motorbike production, each component has a distinct role. The engine generates power, the suspension absorbs shock and the brakes reduce speed. Similar to a motorbike, a software application is also a combination of various functions. Each one is supposed to be as simple and small as possible, and responsible for a single task. For instance, the update payment feature should be separated from the update profile feature. In a broader view, an application should also focus on solving one problem well. Zalo, for example, is a messaging platform, hence its core function is supposed to be messaging. However, this feature is really bad, especially in storing messages, while other features, like news, looking for jobs and social feeds are included, which makes Zalo “bloatware”.
The second principle is Open/Closed Principle, which refers objects or modules are supposed to be open for extension but closed for modification. Let us think in terms of tires. A bike’s core parts, like wheel hubs, axle size and mounting mechanism, stay unchanged while we can extend its functionality just by swapping tires. Street tires are used for smooth roads while off-road tires are used in dirt and mud roads. In software development, if a module or function works well and follows the single responsibility principle, developers are supposed to try to use and extend it before modifying its existing implementation.
The third principle is Liskov Substitution Principle, which is based on the idea that a component should be replaced by another compatible component without breaking the system. Let us consider a desk lamp rated for 60W. A 40W bulb, a 60W bulb or an LED bulb can all be plugged into the lamp, as long as they fit the socket and operate within the expected voltage range. This is possible because bulbs are designed independently of the lamp, relying only on standardized interfaces such as the socket and voltage specifications. In software development, let us take Momo as an example. It allows users to link their bank accounts. Bank account integrations are implemented under the same interface and behavior, so the bank connection management module can treat them similarly, which enhances the readability and maintainability significantly.
The fourth principle is Interface Segregation Principle, which indicates that clients should never be forced to implement an interface that it does not use. Remote control design is a good example. Good design is to have each remote type for each type of device, such as, TV remote for setting volume and channel, and air conditioner remote for setting temperature and fan speed. Meanwhile, bad design is one universal remote with 100 buttons and most of them are unused for each device. In software development, when a lot of modules share the same interface, it should be designed to be small, specific and focused on the needs of its implementations.
The final principle in SOLID is Dependency Inversion Principle, which is about high-level components should not depend on low-level components. Returning to the lamp example, its design should not depend on the internal structure of the bulb. Its roles are simply to provide power and control brightness. Regarding the bank account integration module, it should treat all them based on their shared interface and not depend on each implementation. This approach increases flexibility and simplifies maintenance.
In conclusion, the SOLID principles provide a clear foundation to design maintainable, flexible, readable, and understandable systems. By relating these principles to everyday examples, their core ideas become more intuitive and understandable even for non-tech audiences. In fact, software development shares a lot of principles with manufacturing, since it is influenced by manufacturing practices. Whether in physical systems or software development, good system design is all about simplicity, modularity and well-defined interactions.