Software Design Principles
SOLID Principle
1. Single Responsibility Principle:
Every class should have only one reason to change. The longer the file or class, the more
difficult it will be to achieve this
2. Open Closed Principle
Open for extension and closed for modification
3. Liskov Substitution Principle
Objects of a superclass shall be replaceable with objects of its subclasses without
breaking the application
4. Interface Segregation
5. Dependency Inversion
DRY or Don’t repeat Yourself:
KISS:
YAGNI:
Dependency Injection:
Inversion of Control:
Design Principles
Design Principle is a guideline that is there to help you avoid bad object-oriented design.
Encapsulate What Varies:
Identify the aspects of your application that vary and separate them from what stays the same.
Composition over Inheritance:
Types of Software Architecture Design
1. Domain Driven Design
2. Test Driven Design
3. Behavior Driven Design
Reference:
Don't repeat yourself - Wikipedia
LinkedIn Learning – Design Patterns: Creational
SOLID Design Principles Explained: The Liskov Substitution Principle with Code Examples ([Link])
Misc
1. What is distributed system
Design Principles in snapshot
Composition over Inheritence
Prefer creating objects from smaller components rather than inheriting class behavior.
𝐒𝐞𝐩𝐚𝐫𝐚𝐭𝐢𝐨𝐧 𝐨𝐟 𝐂𝐨𝐧𝐜𝐞𝐫𝐧𝐬 (𝐒𝐨𝐂)
Break the system into independent components, each addressing a specific concern.
𝐂𝐨𝐮𝐩𝐥𝐢𝐧𝐠 𝐚𝐧𝐝 𝐂𝐨𝐡𝐞𝐬𝐢𝐨𝐧
Reduce interdependence between modules while maximizing internal consistency within them.
𝐘𝐨𝐮 𝐀𝐫𝐞𝐧'𝐭 𝐆𝐨𝐧𝐧𝐚 𝐍𝐞𝐞𝐝 𝐈𝐭 (𝐘𝐀𝐆𝐍𝐈)
Implement only what's currently necessary, avoiding over-engineering.
𝐊𝐞𝐞𝐩 𝐈𝐭 𝐒𝐢𝐦𝐩𝐥𝐞, 𝐒𝐭𝐮𝐩𝐢𝐝 (𝐊𝐈𝐒𝐒)
Favor straightforward solutions over complex ones.
𝐈𝐧𝐟𝐨𝐫𝐦𝐚𝐭𝐢𝐨𝐧 𝐇𝐢𝐝𝐢𝐧𝐠
Conceal implementation details, exposing only necessary information externally.
𝐈𝐧𝐟𝐨𝐫𝐦𝐚𝐭𝐢𝐨𝐧 𝐇𝐢𝐝𝐢𝐧𝐠
Minimize dependencies by interacting only with immediate collaborators.
𝐃𝐨𝐧'𝐭 𝐑𝐞𝐩𝐞𝐚𝐭 𝐘𝐨𝐮𝐫𝐬𝐞𝐥𝐟 (𝐃𝐑𝐘)
Eliminate code duplication to enhance maintainability.
𝐒𝐢𝐧𝐠𝐥𝐞 𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐢𝐛𝐢𝐥𝐢𝐭𝐲 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 (𝐒𝐑𝐏)
Each class should have one reason to change, focusing on a single responsibility.
𝐎𝐩𝐞𝐧-𝐂𝐥𝐨𝐬𝐞𝐝 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 (𝐎𝐂𝐏)
Classes should be open for extension but closed for modification.
𝐋𝐢𝐬𝐤𝐨𝐯 𝐒𝐮𝐛𝐬𝐭𝐢𝐭𝐮𝐭𝐢𝐨𝐧 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 (𝐋𝐒𝐏)
Subclass objects should replace superclass objects without altering correctness.
𝐈𝐧𝐭𝐞𝐫𝐟𝐚𝐜𝐞 𝐒𝐞𝐠𝐫𝐞𝐠𝐚𝐭𝐢𝐨𝐧 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 (𝐈𝐒𝐏)
Clients shouldn't depend on interfaces they don't use; prefer smaller interfaces.
𝐃𝐞𝐩𝐞𝐧𝐝𝐞𝐧𝐜𝐲 𝐈𝐧𝐯𝐞𝐫𝐬𝐢𝐨𝐧 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 (𝐃𝐈𝐏)
High-level modules must not depend on low-level modules; both should rely on abstractions.
Reference:
Post | Feed | LinkedIn
Software Design Principles
Great software isn't just about making things work,
it's about creating systems that are maintainable, scalable, and resilient.
These fundamental design principles guide developers toward writing better code.
1./ 𝐊𝐈𝐒𝐒 (𝐊𝐞𝐞𝐩 𝐈𝐭 𝐒𝐢𝐦𝐩𝐥𝐞, 𝐒𝐭𝐮𝐩𝐢𝐝)
➟ The most elegant solutions are often the simplest.
➟ Avoid unnecessary complexity, keep code clear and concise, and focus on essential features.
Remember that code is read far more often than it's written.
2./ 𝐃𝐑𝐘 (𝐃𝐨𝐧'𝐭 𝐑𝐞𝐩𝐞𝐚𝐭 𝐘𝐨𝐮𝐫𝐬𝐞𝐥𝐟)
➟ Every piece of knowledge in a system should have a single, unambiguous representation.
3./ 𝐘𝐀𝐆𝐍𝐈 (𝐘𝐨𝐮 𝐀𝐢𝐧'𝐭 𝐆𝐨𝐧𝐧𝐚 𝐍𝐞𝐞𝐝 𝐈𝐭)
➟ Resist implementing features "just in case."
➟ Build what's needed today.
4./ 𝐒𝐎𝐋𝐈𝐃 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞𝐬
the backbone of object-oriented design:
➟ Single Responsibility - Classes should do one thing well
➟ Open/Closed - Open for extension, closed for modification
➟ Liskov Substitution - Subtypes must be substitutable for their base types
➟ Interface Segregation - Many specific interfaces beat one general interface
➟ Dependency Inversion - Depend on abstractions, not concrete implementations
5./ 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝐨𝐟 𝐋𝐞𝐚𝐬𝐭 𝐀𝐬𝐭𝐨𝐧𝐢𝐬𝐡𝐦𝐞𝐧𝐭
➟ Software should behave as users expect.
➟ Consistency in terminology, conventions, and error messages creates intuitive experiences.
6./ 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝐨𝐟 𝐌𝐨𝐝𝐮𝐥𝐚𝐫𝐢𝐭𝐲
➟ Well-defined, independent modules make systems easier to understand, maintain, and test.
7./ 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝐨𝐟 𝐀𝐛𝐬𝐭𝐫𝐚𝐜𝐭𝐢𝐨𝐧
➟ Hide implementation details to reduce cognitive load.
➟ Users of your code shouldn't need to know how it works internally, just how to use it.
8./ 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝐨𝐟 𝐄𝐧𝐜𝐚𝐩𝐬𝐮𝐥𝐚𝐭𝐢𝐨𝐧
➟ Protect the internal state of objects from external manipulation.
➟ This creates more robust systems by preventing unexpected side effects.
9./ 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝐨𝐟 𝐋𝐞𝐚𝐬𝐭 𝐊𝐧𝐨𝐰𝐥𝐞𝐝𝐠𝐞 (𝐋𝐚𝐰 𝐨𝐟 𝐃𝐞𝐦𝐞𝐭𝐞𝐫)
➟ Components should have limited knowledge of other components.
➟ This "need-to-know basis" approach creates more modular, flexible systems.
10./ 𝐋𝐨𝐰 𝐂𝐨𝐮𝐩𝐥𝐢𝐧𝐠 & 𝐇𝐢𝐠𝐡 𝐂𝐨𝐡𝐞𝐬𝐢𝐨𝐧
➟ Minimize dependencies between modules while ensuring each module has a clear, unified purpose.
➟ This balance makes systems more maintainable and adaptable.
You’d probably agree,
It's easy to nod along with design principles when reading them, but much harder to catch when drifting
away from them in real code.
That's where tools like CodeRabbit can be valuable.
During pull requests, it identifies potential issues that developers might overlook, such as unnecessary
complexity or signs of tight coupling, without being intrusive or slowing down the development process.
Understand,
these tools don't replace human judgment but provide an additional layer of verification that can help
maintain code quality over time.👊