SOLID Design Principle
Udgivet 2017-04-07 - Skrevet af
SOLID Design Principle
So in this article I will be explaining what the SOLID design principle is and why you should care for it. Basically what it tries to achieve, is to make the software developer write clean and maintainable code, which you'll probably quickly will be able to see. It all comes from the book “Agile Software Development, Principles, Patterns, and Practices
” written by Robert C. Martin, so if this sparks your interest I suggest picking up that book.
So let's dive into the five principles that combined is the SOLID design principle.
Single Responsibility PrincipleA class should have only one reason to change.
This principles describes that each class only should have one responsibility. If it has more than one, the code should be refactored until each class only has one responsibility. This is all about reducing complexity and decoupling.
Interface Segregation Principle
As the name reveals, this principle is all about how we develop our interfaces. Interfaces should only contain methods that should be there, as classes implementing the interface will also have to implement these methods. Instead of forcing one fat interface, many small interfaces are preferred.
Liskov's Substitution PrincipleDerived types must be completely substitutable for their base types.
This is somewhat of an extension to the principle below (Open Close Principle), as this principle state that a derived class should extend the base class without changing its behavior. In other words, the new derived class should be able to replace the base classes without changing anything else in the code.
Open Close PrincipleSoftware entities like classes, modules and functions should be open for extension but closed for modifications.
This is a generic principle that states that when creating extension for classes you shouldn't have to modify them. It is generic because it can be applied to so much more than classes, and is great for thinking in modules and decoupled. Backwards compatibility and regression testing are some of the reasons why it's relevant.
The principle can be ensured by using an abstract class with concrete classes below for implementing the specific behavior.
Dependency Inversion PrincipleHigh-level modules should not depend on low-level modules.
This principle state that high-level classes shouldn't be dependant on details in low-level classes. Instead an abstraction layer is introduced in between them to increase decoupling. Instead of writing abstraction classes based on details, details should be written based on abstractions.
When boiling it all down, what we are left with are basically these three characteristics that we are trying to avoid:
|Rigidity ||Changing a program is hard, because it affects to many other parts. |
|Fragility ||Introducing change to program breaks unexpected parts. |
|Immobility ||Code reuse is hard, because it is all entangled. |
All of these three characteristics scream lack of decoupling.
Der er ingen kommentarer.