Can any project be suited to the principles preached by SOLID? What are the steps to this?

Asked

Viewed 66 times

4

I am trying to adapt one of my projects to the standards of SOLID, but I’m not getting out of ground zero. The project in question can be found at: https://github.com/crphp/webservice

After some attempts the following doubts arose:

  • Every project is a liability of adequacy to all 5 principles advocated by SOLID standards?
  • These principles have some hierarchical implementation dependency?
  • I believe the principle SRP can be considered a starting point, but then, what would be the next principle to be met, there is a logical order (not obligatory in itself, but logical)?
  • In one of my advances, I tried to meet the principle ISP, however, I was unable to determine interfaces + common signature. I even came to a common interface, however the signature of this interface diverged between the project classes (Crphp src Soap.php and Crphp src Clientegenerico.php). What to do in these cases? Does a project (module) so small require the creation of more than one interface to try to overcome this barrier?

The 5 principles mentioned above are:

  • SRP - Single Responsibility principle
  • OCP - Open/closed principle
  • LSP - Liskov substitution principle
  • ISP - Interface segregation principle
  • DIP - Dependency inversion principle

Source: https://medium.com/thiago-aragao/solid-princ%C3%Adpios-da-programação-orientada-a-objetos-ba7e31d8fb25

Show 2 more comments

1 answer

2

There is no sequence to "tailor" a project to SOLID!

The acronym refers to development principles that should, whenever possible, be followed to avoid problems in software over time, especially if you work as a team.

There will be times when it will be necessary not to follow some principle. As long as this decision is made aware of what is being done, there is no problem. The important thing is to know why SOLID.

SOLID exists to help developers fix a number of problems that can happen within Object Orientation. In the paper by Robert Martin, responsible for disseminating the principles (Design Principles and Design Patterns), is talked a lot about change and refactoring, a very important feature for any evolvable software.

Very rigid systems (resistant to changes) take a lot of work to evolve. The opposite is also worrisome, in very fragile systems the simple change of one part can break another ten across the system.

SOLID principles aim to make the software more maintainable and easy to understand. In other words, SOLID will make the software:

  • More organized;
  • Open to receive improvements;
  • Evolutive: being updated will not have unwanted side effects;
  • Easy to be tested;
  • Less prone to code repetition;
  • Easy to have your modules repurposed.

The opposite should also be considered, i.e., systems where SOLID principles are not observed tend to:

  • Possess non-standard, disorganized and macaroni code;
  • Have swollen classes, with explosion of methods and difficult to understand;
  • Be very strict in some parts, making changes difficult;
  • Be very fragile, breaking other parts of the system with ease;
  • Have lots of code repeated throughout the system;
  • Be very difficult to test.

The subject is vast and very interesting. For more information, I suggest you read The SOLID principles.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.