DEV Community

Cover image for SOLID Design Principles
Nozibul Islam
Nozibul Islam

Posted on

SOLID Design Principles

What are SOLID Design Principles?

The SOLID design principles are a set of five software design guidelines that aim to make software development more efficient and maintainable. By applying these principles, we can design complex systems in a way that makes them easier to modify, extend with new features, and fix bugs, all while increasing code reusability. These principles help protect us from bad design when building software systems.

The SOLID principles were introduced in the early 2000s by Robert C. Martin, also known as "Uncle Bob," in his book "Agile Software Development: Principles, Patterns, and Practices." According to him, there are three major characteristics of bad design that should be avoided:

  • Rigidity: This is when a small change in one part of the system requires changes in many other parts, making the system difficult to modify.
  • Fragility: This happens when changes to one part of the system unexpectedly cause other parts to break, leading to system instability.

  • Immobility: This is when certain parts of a system are so intertwined with the rest that they cannot be easily reused in other systems.

Though originally targeted toward object-oriented programming, these principles can be applied to any programming paradigm if understood as a general philosophy.

SOLID Principles Overview:

  • S - Single Responsibility Principle (SRP): A class should have only one reason to change, meaning it should have only one job or responsibility.

  • O - Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

  • L - Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of a subclass without altering the correctness of the program.

  • I - Interface Segregation Principle (ISP): No client should be forced to depend on methods it does not use. Interfaces should be specific to the needs of the client.

  • D - Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions, and abstractions should not depend on details.

By adhering to these principles, code becomes more organized, understandable, and easier to maintain over time.

Note: In the following lessons, the SOLID principles have been discussed.

Top comments (0)