The hierarchy of design principles, or the most important words for engineers
In this short note, I would like to systematize (namely, arrange into a hierarchy) many popular principles for designing software applications (test-driven development, OOP, SOLID, etc.), and also consider the implications of this hierarchy.
In particular, such a hierarchy (I hope) will make it possible to better prioritize development and professional growth, better understand old technologies and learn new ones faster. When a new development paradigm (a la test-driven development) emerges, you can quickly incorporate it into this hierarchy and, therefore, quickly understand what principles the creators of the paradigm came from and how to use it correctly. For beginners in programming, an article may be useful as a review of existing principles.
And as the most basic, I think it is reasonable to consider McConnell’s principle of “managing complexity / minimizing technical complexity”. And the most important ways to minimize complexity are modularity and abstraction.
This short article will consist of several sections:
The basic rule for locating the design principles in the hierarchy is as follows: if you can follow principle A, but refuse or not know about admission B, then A is a more basic design principle. For example, you can deal with OOP, but not yet read about the Gang of Four design patterns — this will not prevent you from writing programs using OOP; therefore, OOP is a more basic principle. Or, for example, you can opt out of OOP (or some of its attributes — for example, inheritance and polymorphism), but, nevertheless, continue to write modular C programs with clear interfaces of modules and levels of abstraction. Therefore, modularity and abstraction are more basic principles than OOP.
')
So, some of those few design principles known to me, I prefer to be located on the following levels:
In the picture it will look like this (the picture includes hierarchical links, which compares favorably with the list above):
I assume that for people familiar with all the concepts in the diagram, the communication logic should be transparent. Nevertheless, I will focus on the basic concepts, connections, and important and slippery points.
What is complexity management / minimization of technical complexity (while preserving the necessary functionality, of course) and why it can be considered a basic design principle, you can find out in Steve McConnell’s excellent book “Code Complete”, chapter 5. The discussion begins with the term “complexity management”, but personally it seems to me less informative.
The KISS principle is in some sense identical to the minimization of technical complexity, but since there is a separate abbreviation for it, I also included it in the diagram with a special block.
Many novice programmers (and myself, which is already there) are delighted to share with each other the observation that the differences in the syntax of languages ​​are not critical, because almost all mainstream languages ​​share the OO paradigm in one form or another. But a completely similar statement can be made with respect to the principles of design, whether it is OOP or procedural programming, namely: these principles are similar in their desire to provide means of abstraction of data and operations (structures and procedures, classes and methods) and system partitioning into modules .
Therefore, I would like to dwell in greater detail on modularity and abstraction — the concepts discussed in the excellent book Structure and Interpretation of Computer Programs (SICP; the first edition is freely available, the second — not) —and quote an introduction to This book, which, in my opinion, contains the most important words for engineers.
The most important words for engineers
“We control complexity by building abstractions. We have integrated control systems for combining the standard, well-understood parts in a “mix and match way”. "We control the complexity of the design, and each of which emphasizes the particular aspects of the design and deemphasizes others."
Once again: modularity and abstraction — the basic ways of managing complexity; and this, in my opinion, the most important ideas about software development and engineering activities in general, which I happened to meet (if someone read more interesting, welcome to the comments). What can be compared with the pleasure of knowing that you do not need to remember how a class (or even a library) used inside works, in what order to call its methods, what restrictions are imposed on parameters? —Because all of this doesn’t matter, because the class forms the correct abstraction and saves the user from details: methods can be called in any order, their semantics and semantics of parameters are obvious, conflicts with simultaneously used libraries cannot be, etc.
If you want to get deeper into these principles, I warmly recommend SICP and, as usual, McConnell. [Remarks: Of course, many of these books will be known, and the quotation from SICP will seem trivial, but among, at least, my friends, professional and highly skilled programmers, many have not heard of SICP — someone skipped lectures, and studied physics And if you know a similar book, but in modern times, welcome to the comments].
Of course, test-driven development and domain-driven design are hard to imagine without the use of OOP, and, therefore, they should be studied after OOP, so they could be placed on the same level as the design patterns.
On the other hand, test-driven development is quite possible to use for C programs that do not use polymorphism or inheritance, but when writing it is possible to design an architecture for testing individual procedures and write such tests. The same applies to domain-driven design: the program can be written in C, but completely in the spirit of DDD. That is why they are placed on the same level as the PLO.
If the program architecture is replete with design patterns and fashionable things like Dependency Injection / Inversion of Control, this does not mean that the program will be easy to understand and accompany. The reason lies in the fact that there are more basic design principles — modularity and abstraction, and an architect can easily lose sight of them in the pursuit of patterns. Remembering this hierarchy, as an architect you will no longer make such a mistake, and as a developer you can always easily verbalize for the architect why he is wrong in making such a mistake.
The hierarchy of design principles, I hope, will make evident several facts:
For example, that OOP is not the only means of creating levels of abstractions, and that procedural programming is intended for the same purposes.
Thank you all for your attention!
In general, since I advertised SICP, also called the Book of the Magician, in this article, it is necessary to recommend the Cinderella Book and the Book of the Dragon, which are no less fundamental, to complete the picture. So, the list of fabulous books:
Again, many of these books will seem commonplace (especially the Book of the Dragon), but I think there are quite a few people who read about them for the first time in this article.
In particular, such a hierarchy (I hope) will make it possible to better prioritize development and professional growth, better understand old technologies and learn new ones faster. When a new development paradigm (a la test-driven development) emerges, you can quickly incorporate it into this hierarchy and, therefore, quickly understand what principles the creators of the paradigm came from and how to use it correctly. For beginners in programming, an article may be useful as a review of existing principles.
And as the most basic, I think it is reasonable to consider McConnell’s principle of “managing complexity / minimizing technical complexity”. And the most important ways to minimize complexity are modularity and abstraction.
This short article will consist of several sections:
- Hierarchy construction rule
- Hierarchy overview
- Remarks
- Consequences
Hierarchy construction rule
The basic rule for locating the design principles in the hierarchy is as follows: if you can follow principle A, but refuse or not know about admission B, then A is a more basic design principle. For example, you can deal with OOP, but not yet read about the Gang of Four design patterns — this will not prevent you from writing programs using OOP; therefore, OOP is a more basic principle. Or, for example, you can opt out of OOP (or some of its attributes — for example, inheritance and polymorphism), but, nevertheless, continue to write modular C programs with clear interfaces of modules and levels of abstraction. Therefore, modularity and abstraction are more basic principles than OOP.
')
Hierarchy overview
So, some of those few design principles known to me, I prefer to be located on the following levels:
- minimize technical complexity
- modularity and abstraction; Keep it simple, stupid (KISS) ; Don't repeat yourself (DRY)
- procedural programming; OOP; test-driven development (TDD) ; domain-driven design (DDD)
- design patterns ( Fowler , Gang of Four , MVC ); SOLID
In the picture it will look like this (the picture includes hierarchical links, which compares favorably with the list above):
Remarks
I assume that for people familiar with all the concepts in the diagram, the communication logic should be transparent. Nevertheless, I will focus on the basic concepts, connections, and important and slippery points.
Minimization of technical complexity
What is complexity management / minimization of technical complexity (while preserving the necessary functionality, of course) and why it can be considered a basic design principle, you can find out in Steve McConnell’s excellent book “Code Complete”, chapter 5. The discussion begins with the term “complexity management”, but personally it seems to me less informative.
The KISS principle is in some sense identical to the minimization of technical complexity, but since there is a separate abbreviation for it, I also included it in the diagram with a special block.
Modularity and abstraction, or the most important words for engineers
Many novice programmers (and myself, which is already there) are delighted to share with each other the observation that the differences in the syntax of languages ​​are not critical, because almost all mainstream languages ​​share the OO paradigm in one form or another. But a completely similar statement can be made with respect to the principles of design, whether it is OOP or procedural programming, namely: these principles are similar in their desire to provide means of abstraction of data and operations (structures and procedures, classes and methods) and system partitioning into modules .
Therefore, I would like to dwell in greater detail on modularity and abstraction — the concepts discussed in the excellent book Structure and Interpretation of Computer Programs (SICP; the first edition is freely available, the second — not) —and quote an introduction to This book, which, in my opinion, contains the most important words for engineers.
The most important words for engineers
“We control complexity by building abstractions. We have integrated control systems for combining the standard, well-understood parts in a “mix and match way”. "We control the complexity of the design, and each of which emphasizes the particular aspects of the design and deemphasizes others."
Once again: modularity and abstraction — the basic ways of managing complexity; and this, in my opinion, the most important ideas about software development and engineering activities in general, which I happened to meet (if someone read more interesting, welcome to the comments). What can be compared with the pleasure of knowing that you do not need to remember how a class (or even a library) used inside works, in what order to call its methods, what restrictions are imposed on parameters? —Because all of this doesn’t matter, because the class forms the correct abstraction and saves the user from details: methods can be called in any order, their semantics and semantics of parameters are obvious, conflicts with simultaneously used libraries cannot be, etc.
If you want to get deeper into these principles, I warmly recommend SICP and, as usual, McConnell. [Remarks: Of course, many of these books will be known, and the quotation from SICP will seem trivial, but among, at least, my friends, professional and highly skilled programmers, many have not heard of SICP — someone skipped lectures, and studied physics And if you know a similar book, but in modern times, welcome to the comments].
Test-driven development and domain-driven design
Of course, test-driven development and domain-driven design are hard to imagine without the use of OOP, and, therefore, they should be studied after OOP, so they could be placed on the same level as the design patterns.
On the other hand, test-driven development is quite possible to use for C programs that do not use polymorphism or inheritance, but when writing it is possible to design an architecture for testing individual procedures and write such tests. The same applies to domain-driven design: the program can be written in C, but completely in the spirit of DDD. That is why they are placed on the same level as the PLO.
Consequences
Right development priorities
If the program architecture is replete with design patterns and fashionable things like Dependency Injection / Inversion of Control, this does not mean that the program will be easy to understand and accompany. The reason lies in the fact that there are more basic design principles — modularity and abstraction, and an architect can easily lose sight of them in the pursuit of patterns. Remembering this hierarchy, as an architect you will no longer make such a mistake, and as a developer you can always easily verbalize for the architect why he is wrong in making such a mistake.
The right priorities in professional growth and training (junior staff or students)
The hierarchy of design principles, I hope, will make evident several facts:
- Before recommending to the junior engineer a book about OOP, it is better to give a book about modularity and abstraction (for example, SICP)
- before recommending a book about design patterns, it is better to give a book about OOP
- etc.
Better understanding of existing technologies
For example, that OOP is not the only means of creating levels of abstractions, and that procedural programming is intended for the same purposes.
Thank you all for your attention!
PS
In general, since I advertised SICP, also called the Book of the Magician, in this article, it is necessary to recommend the Cinderella Book and the Book of the Dragon, which are no less fundamental, to complete the picture. So, the list of fabulous books:
Again, many of these books will seem commonplace (especially the Book of the Dragon), but I think there are quite a few people who read about them for the first time in this article.
Source: https://habr.com/ru/post/169487/
All Articles