On the Principles in Programming
SOLID contains 5 principles of software design, but not all existing principles. There are several:
- SOC Separation of Concerns;
- DRY Don’t Repeat Yourself;
- YAGNI You Ain’t Gonna Need It;
- KISS Keep It Simple, Stupid;
- REP The Release Reuse Equivalency Principle;
- CCP The Common Closure Principle;
- CRP The Common Reuse Principle;
- ADP The Acyclic Dependencies Principle;
- SDP The Stable Dependencies Principle;
- SAP The Stable Abstractions Principle;
- among others.
The principles cited above are not SOLID, but are also principles of software design. They are as important as SOLID so that the designer can know what is positive and what is negative.
I’m not saying some are better than others, or imposing a hierarchy. I say, however, that all are important to form the knowledge of a designer. Knowing which practices can bring benefits and which can bring disastrous headaches as a software evolves is the search for every good designer. The principles guide this knowledge.
Since the principles arose because of a need to deliver quality software in as little time as possible. At a time when big names in computer science argued that "software should be easy to maintain"!
Understanding that: "as little time as possible" does not mean delivering running. Many use the word Agile, stating that software should be done fast, but in a wrong direction. The meaning of "agility" is to deliver quality software. Quality is less work to change, less work to fix. This results in less cost and less time to maintain and evolve the software.
As the Maniero said: "I like other principles with priority, two of them are YAGNI and KISS which preach that you should do everything simple and only what you need. Of course with some care not to overdo it. In fact KISS says to do simple but not simple, and YAGNI is not saying to leave the application completely naked". Principles help to do well, but we must learn to avoid exaggerations.
The experimentation and analysis that gave rise to the principles were not done by heated programmers, but by people who knew what they were talking about, people from the academic (MIT, Oxford, etc.) and business of great importance (IBM, for example). This experimentation took place over an extended period (more than 30 years) of research, so it is difficult for our immediate generation to understand them. It is not enough to give Control+C and Control+V.
Much of these principles have emerged in the scientific environment, in large universities. The SOLID LSP (Liskov Substitution Principle), for example, was made by Barbara Liskov of MIT in one of his publications.
When we see articles and strong criticism in blogs about "why to use principles or not", we realize how far people are from the real goal of these precious tools for software designers. Principles exist to provide:
- Ease of maintenance;
- Reuse of code in other projects;
- Deliver evolutions and corrections as soon as possible.
See the Manifesto for Agile Software Development.
Another important thing: The goal is not to follow all principles to the letter with iron and fire at all times!! If so, the software becomes very difficult to do, especially for less experienced programmers. Requirements and compliance with rules at all costs is not the goal!! The importance of the principles is related to knowledge, allow the designer to know what has proven to work and what does not work in several situations so that he decides, by himself, the best way to make a software that suits the reality of his company.
About SOLID
In fact, Robert Martin did not "create" the SOLID principles, but catalogued several principles that, according to his experience, would be the most important for synthesizing all the others (see Design Principles and Design Patterns). In other words, understanding and complying with these principles would be fulfilling, consequently, the others existing in the literature.
From this list, he separated 5. In the book Clean Architecture, Martin explains that around 2004 his friend Michael Feathers :
"sent him an email saying that if he reorganized the principles of his catalogue, the first letters would spell the word SOLID (solid
in Portuguese)".
It was at this point that the acronym was born.
Robert Martin took 20 years to formulate the catalogue, based on tests and experience of him and his colleagues in various programming languages. It was not an assumption, it was joint or referenced experimentation of the works of various computer science and software engineering names: Barbara Liskov, Bertrand Meyer, David L. Parnas, Dave Thomas, Edsger Dijkstra, Kent Beck, Larry L. Constantine, Alistair Cockburn, Martin Fowler, Andrew Hunt, Michael Feathers and several others. Just look up some of those names on the Internet.
For the sake of truth, little is Robert Martin’s, most of the principles he catalogued come from the literature of some of these names. Below are some of the references used by Martin to synthesize and name the 5 principles.:
SRP - Principle of Single Liability: David L. Parnas and Edsger Dijkstra (author of SOC Separation of Concerns);
OCP - Open Closed Principle: Bertrand Meyer and Larry L. Constantine (among the first to talk about coupling and cohesion);
LSP - Liskov Substitution Principle: Barbara Liskov;
ISP - Principle of Interface Segregation: based on the Pattern design Template Method, of the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides);
DIP - Inversion of Dependencies Principle: based on the work of Grady Booch, Meilir Page-Jones and Barbara Liskov;
In one of his old speeches, Martin states that the principles are important to Senior designers and aspiring to this degree of knowledge, with long-standing experience in software design. It also states that the new programmers, with little experience might not understand the real meaning of the principles and misrepresent them, even with good intention, when trying to summarize them to pass on to their colleagues.
This explains a lot! In most places where you talk about SOLID (blogs, websites and literatures), it is so short that you can’t understand. SOLID is not simple but is simple to practice. The transmission of anemic information has made SOLID’s journey difficult for us Brazilians to truly understand.
Tip: Search Robert Martin’s Youtube talks, there are several old and new.
The DIP (Dependecy Inversion Principle)
A great example of this confusion is the functioning of Principle of Inversion of Dependence. It is very simple and states that if one class is to depend on another, it must be more stable.
"the code implementing the high-level directive should not depend on the
code that implements low-level details" (Robert Martin, Design Principles and Design Patterns).
In other words, if the class To class-dependent B, B should be more stable than To, so that dependencies between classes always move towards stability, depending on modules more stable than itself.
If your program depends on a module where the methods change with each version, for example, you will always have the job of updating all classes that use it. The more stable dependencies are, the less change, the more agility, the more profit and the less time lost.
Simple and obvious, how solid software should be.
Completion
It is not a matter of defending or criticizing SOLID. It is a matter of defending knowledge, and criticizing the delivery of bad software.
It is very easy to make bad software, so it is important to know (really understand) how more experienced people that we have dealt with the same problems and solved them.
For an idea to become one principle or a pattern, It is necessary that, first, it is proven that many projects made use of this idea and achieved the same results. This is only possible with time, with experience, with the spirit of research and reading of good authors.
Below are references to the works used by Martin in formulating the principles:
- CONSTANTINE, Larry L. Structured design. IBM Systems Journal, VOL13, NO 2, 1974;
- DEMARCO, Tom. Structured Analysis and System Specification, Press Computing Series, Yourdon, 1979;
- DIJKSTRA, Edsger W. On the role of Scientific thought. Burroughs Research Fellow, Netherlands, 1974;
- GAMMA et all. Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995;
- BOOCH, Grady. Object Solutions, Addison Wesley, 1996;
- JACOBSON, Ivar. Object Oriented Software Engineering a Use Case Driven Approach, Addison Wesley, 1992;
- LISKOV and WING. A behavior notion of subtyping. Carnegie Mellom University: Pennsylvania, USA, 1994. Available in https://www.cs.cmu.edu/~Wing/Publications/Liskovwing94.pdf. Accessed on 03/08/2019;
- MEYER, Bertrand. Object-Oriented Software Construction. Prentice Hall, 1988;
- PAGE-JONES, Meilir. The Practical Guide to Structured Systems Design, 2d. ed., Yourdon Press Computing Series, 1988;
- PARNAS, David L. On the Criteria To Be Used in Decomposing Systems into Modules. Carnegie-Mellon University, 1971.
I must assume that the negatives are fans of SOLID? :)
– Piovezan