SOLID is all that they say?

Question

Related: What are the SOLID principles?

I ordered my "Agile Principles, Standards and Practices in C#" by Robert C. Martin and one of the reasons is SOLID. But I’m reluctant about SOLID.

I don’t even know all the principles. I know SOLI, D is missing. The case is that I see the principles and I think "okay, so what?". Some of them seem to me that don’t come with parameters telling you where to apply them, or how. They’re kind of like design patterns: you first find a situation where they fit in, and then you apply it if they land well in that situation.

Moreover, they seem to me only a sparse set of demands that are individually well-founded, but together they have no cohesion at all. Why will my code stay solid if I apply them?

Who defends them puts them on a very high level. But I do not know if they are all this. There are those who criticize (if to read only one of the ones listed below, read the first).

Critique, who generally agreed: Why I don’t Teach SOLID

Criticism and defenses: SOLID is OOP for Dummies

Another criticism: Not-so-SOLID OOP Principles

Critical: Re: Why Every element of SOLID is Wrong

Defense against some criticisms: In Defense of the SOLID Principles

I would like to see as impartial an assessment as possible of the applicability of these principles, and whether they bring all the benefits that.

Answer 1

The first mistake people make is to think that Uncle Bob is the creator of SOLID. This acronym was created by Michael Feathers. And the concepts individually were created by other people, although Robert Martin gave his version of how each of the five items should be interpreted. So SOLID is one more of those things that everyone understands in a way, and therefore nobody knows for sure what it is, and it doesn’t serve as a good parameter, but it’s good tips for thinking and discussing the subject.

And they’re kind of purposefully vague. That’s one of the criticisms that you make at first. His problem is that if the person understands everything he is, he doesn’t need it, and if the person just uses it as a basis for what he needs to accomplish the person becomes "bitchy" and makes mistakes by following "magic formula".

SOLID’s ideas are good, but you always need to understand the whole context of it. Understand it in depth to know when and how to apply it. Overuse is a problem, like almost everything we do.

In general his problem is to put a lot of clumsiness, a lot of mechanism in what should be the domain. And it does not always produce the wonder that is expected of it, even when done right. It will still need a lot of refactoring. If it’s for refactoring, just put stuff on it when you need it.

Another related problem is that it mixes levels of abstraction, you find in the same code things that express your domain and things that help your code "work better".

What you need to understand is that certain relationships between objects are difficult to break down and this is what matters throughout SOLID. Do not create dependencies where refactoring will be too complicated. The secret is to eliminate dependencies, is to allow composition. What matters is cohesion, a very old concept.

What software are we talking about?

This is something that is always left out. Are we talking about a game? Something embedded? An internal application? A commercial product? From a library or framework public? Or something that has no importance or long life time?

Relationship with OOP

Some say it helps OOP. Some say it goes against, or at least it’s not about OOP. I don’t think it’s about OOP, everyone talks about one thing and in general talks about modularization, or even doing the opposite of what OOP preaches.

Important principles

I like other principles with priority, two of them are the YAGNI and the KISS who preach that you should do everything simple and only what you need. Of course with some care not to exaggerate. In fact KISS says to do simple but not simple, and YAGNI is not saying to leave the application completely naked.

Interestingly, the people who created and defend SOLID also strongly advocate legacy code, continuous improvement, and refactoring. Well, do not use SOLID until it is necessary to meet the two principles above and it can be applied when necessary in legacy code doing refactoring. But only when the gain pays off.

Another principle I like very much, the one I like the most, is the DRY. From my experience in more than 35 years developing software, and in general working years on the same software, what makes maintenance easier is DRY. I even exaggerate the use of it, but it does not bring me big problems. Having a canonical information of the system is fundamental. When you start spreading the information, you lose control. And if you need to change something that’s spread, you’re going to have problems, and it’s going to get a lot more confusing to understand what’s going on. Of course, the wrong use trying to reduce a circumstantial repetition can cause problems, why I always say you need to know how to model with mastery, understand the problem with depth.

I find it regrettable that they are creating a wave against DRY. DDD is very NOT DRY (in parts), SRP says that there should be a reason to change a class, but not that a change of one class should not change others, and not having to change other places is more important.

Moreover, they seem to me only a sparse set of demands that are individually well-founded, but together they have no cohesion at all. Because my code will be solid if I apply it?

I agree. But I think they only put it together to sell the idea more easily. Forget that the software will be more solid. Understand that this in itself is just marketing. Stick to the individual principles themselves and understand them. Or original principles that are more important and that SOLID was created to market them best.

People like to buy these ideas, and the more they repeat it, the more people want to follow it. It creates a virtuous circle for those who understand what they are doing and a vicious circle for those who do not understand. When people start doing it just because they read that it’s something they have to do they’re doing it by definition, even if it works out by coincidence.

Dependency Inversion

Just what you haven’t learned yet, which is usually implemented with this DI (I told you about him), is one of the most critical things. Because it is mostly created solely to facilitate the test. Nor do they speak of what. And it’s used ideologically. Anything that’s put into the code without a need for it itself I’m against. If it is used because the software will look better it is ok. If it is used to give flexibility and this is optional too ok. If it’s just for testing there are other ways to accomplish it. It’s usually very simple to add this later.

Criticism at every point

• SRP

  It’s cool, but it’s confusing. At first people understood it was DRY, today they say it’s something else and it worries me. It’s just about modularizing.

  One of its problems is that it can encourage creating too many classes, too many functions, making the code too complex, having to create link elements, facilitators, or very verbose codes to express what it needs because of the existence of so many components. And having so many things makes it easier to handle them individually, but it gets very complicated to maintain and use.

  It is very difficult to define well what is unique responsibility. Almost everyone sends to create a Cliente that derives from PessoaJuridica, and the moment you do this Cliente has at least two responsibilities, but "no one" sees this. It is the fault of the canonical example of the past that they use to teach OOP.

  In many cases a change in one class requires the change in another associated way to function properly and in a way that has no way you know automatically. Refactoring to add something of SOLID late is usually mandatory in languages with a good type system, otherwise it does not compile. In other languages it can cause problems at runtime, unless one creates in the code a typing control system, which indicates that one has chosen the wrong language to do that.

  To tell you the truth we don’t have the right tools to deal with it, even if it’s desirable. And no one creates.

• OCP

  As a general idea it is good, but in practice it creates complexity because everything requires making new versions. It is common to violate DRY because of this (ironically it should be the opposite). One way to avoid this is to separate responsibilities well, but when you do it the right way you start running away from OOP.

  In general she preaches inheritance abuse, even in the right way, but still use inheritance where perhaps you can do it in a more flexible and easier way with composition.

  When everything is well planned and a new type is created inherited from some kind that was thought to be the basis of something else, it can work. When you take something from one domain and inherit it in another domain to make it more flexible, there is something wrong, then it is better to let the object deal with the differences.

  One of the criticisms I make is that she sees inheritance in a basic way. Today some languages have more sophisticated mechanisms that allow something that is in the middle.

• LSP

  The idea is very good, mainly because she says avoid making inheritance in a sloppy way, without much sense. This avoids reuse by reuse, it needs to have a reason to inherit. In the background it preaches the composition.

• ISP

  It’s usually good, but it’s more about contracts. The bad part is when they exaggerate just to follow this. As long as you can refactor it’s best not to secrete so much and then whisper when necessary. Don’t get me wrong, it’s good to segregate, but be careful not to overreact. The worst is when the person creates an interface just by creating, without it being actually used. This is a mistake that only sins those who are very fanatic about SOLID and do not understand it fully, but among developers who are not novices it is common to fall into this trap.

• DIP

  I told you above.

Completion

I like the idea of SOLID as tips for things you should observe when developing software and starting points to study more on the subject.

None of these things guarantee quality in software. Quality is given when one knows what one is doing and is dedicated to doing it correctly.

If Uncle Bob does this and it works out for him, fine. But are you sure about this? Doesn’t he end up doing the same work that you would do by not following SOLID when it has to be serviced? Does he not have more facility just because he knows how to do the independent right to follow SOLID or not? We have no answers to this.

Who proved that SOLID is good? Should we just believe that it is? It is religion?

SOLID is good, its irresponsible use is not. The benefits exist in specific cases when used correctly. Don’t be alone in SOLID and don’t demand to use it all.

To be fair there are much worse things, SOLID is not so bad, but to be fair has better principles and guides that meet the same goal. And if it’s applied with a less object-oriented ideal maybe it works better. Perhaps his biggest problem is the examples used and solutions offered.

In general the important thing is to know the pros and cons of it, it is silly to say that it is bad or good without a context.

I need to find time to substantiate this answer a little more. I have the basis of the problem, but I still need more research to not leave too much in the air. In essence I put in Portuguese with my words what is in all links of the question, and some more knowledge.

Answer 2

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.

Answer 3

SOLID

SOLID principles serve as metrics in object orientation. Applying SOLID is not like a design standard, because its concepts are not formulas, but ideas that can be applied in the code. To apply the principles there are no strict rules.

Solid is much more a reference to be able to identify a quality code, serving as a basis to know how to create a code that is more favorable to maintenance and changes. Applying these concepts is not an obligation, everything should be done with weighting, because no rule should be followed blindly.

Finally, knowing these principles helps a lot to understand object orientation, but it is always important to have critical sense, because something that is used or defended without consideration loses its meaning. I find SOLID essential, but it is not a magic formula to develop a quality code.