This series is a free and very short retelling of Robert Martin's (Uncle Bob's) 2018 book Clean Architecture. The previous part is here .
Design principles
The SOLID principles tell us how we can combine our functions and data into classes, and how these classes should be interconnected. That is, these principles are at the mid-level. However, they also apply to the component level (high-level architecture).
SOLID principles began in the late 1980s and stabilized in the early 2000s.
SRP: Single Responsibility Principle
Historically, this principle has been formulated as follows: a module should have one and only one reason to change.
However, Uncle Bob suggests a different, more precise formulation: the module should be responsible for one and only one actor .
A module is some related set of functions and data structures.
An example of a violation of the principle: the class Employee
with three methods calculatePay()
, reportHours()
, save()
. All three of these methods apply to different actors. calculatePay()
- this is the accounting department reportHours()
- this is the personnel department save()
- this is the database administrator. If one of the actors asks to make changes to their method, then this can break the logic of other methods. It also makes it difficult to merge changes from different actors.
– . , .
OCP: /
, .
: .
.
: -. - . OCP , , , . , , , . , .. .
, , .
OCP , .
LSP:
: S T, T S - .
, , .
LSP: /.
LSP: , REST- . . , , .
ISP:
, .
, , .
, . ISP , , , . , , . .
DIP:
, .
Java , .
, , , java.lang.String
. . , , . .
. , , .
.
, ? :
In the future, we will refer to the DIP principle more often than to other principles, because it dictates to us the most important rule for building a competent architecture: the Dependency Rules .
To be continued...