ePrivacy and GPDR Cookie Consent by Cookie Consent

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 Principle

A 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 Principle

Derived 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 Principle

Software 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 Principle

High-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.

In Conclusion

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.

Tilføj kommentar