DEV Community

SOLID - The Simple Way To Understand

Kevin Toshihiro Uehara on May 01, 2024

Hi there!!! How have you been doing? Are you all right? I hope so! Today I'm going to talk about a theme that's everyone talks or write about. But...

Read full post

João Angelo • May 1

Hi Kevin Toshihiro Uehara,
Your tips are very useful
Thanks for sharing

wahid-Nabi • May 3

Really great article, simple and understandable.

Alex P • May 8

And don't forget about principles:

DRY – do not repeat yourself
WET – write everything twice

Sometimes they are very important too 👍

Alex Lee • May 7

the tips is so cool.
but .. a lot of spelling errors. (my english is not so good)

Gabriel Simas • May 2

Hi Kevin.
Another BrazDev here!

I've fascinating with your courage in writing a article in plain english!

Thanks for encouraging me as well!

Mohit Singh • May 7

The examples make the concepts very easy to understand.

Akash • May 6

Great article.
Easy to understand!

Héctor Serrano • May 6

Tks Kevin.
The difficult thing is to be simple!

Kishan V P • May 14

Thank you for all great posts !

isaias • May 8

Thank you for simplifying the understanding of SOLID principles.

Joel Jose • May 8

Nice one. Its so easy to understand.

Ahmedalmogy • May 8

neat explain ,thank you , waiting for more articles such that .

Yann Schepens • May 27 • Edited

Hi, thank you for the article and the effort to explain complicated concept.
To complete your article, there is another way to interpret the Single Responsability (which extends your explanation). "One class must change for only one reason". For exemple (pseudocode)

class Client {
    String id;
    String password;
    String name;
    String address;
    String lastCommand;
    String firstConnection;
}

You should split it in two classes, because actually your class manage two concepts : The user account on the platform (with connexion, password, etc.) and the client who have commands on the platform (with list of commands, address, all related to commands). Even if there are some duplicated information, there are two different thing:

class User {
    String id;
    String password;
    String firstConnection;
}

class Client {
    String id;
    String name;
    String address;
    String lastCommand;
    String firstConnection;
}

For the LSP, which is really complicated, I totally agree with you, it's very complicated to explain. Your explanation miss an important concept reading "A child class must replaced parent class without break the program". We can understand this rules this way "Child class must not be more restrictive than a parent class" or "A child class must accept all the parent class can do (method signature and returns)". For exemple :

interface User{}
class Client implements User{}
class Admin implements User{}

class MessageSender {
    sendMessageToUser(User u) {}
}

class NiceMessageSender extends MessageSender {
    sendMessageToUser(User u) {
        if (u instanceof Admin) {
            thrown new Exception("Could not send nice message to admin");
        }
    }
}

If you do that the program could be broken.

Any way, thank you for your explanation this was just to complete your explanation.

Jon-117 • May 21

I really appreciate that you're posting and making the information accessible, but this is painful to read. The ideas here are laid out well, but I can't ignore how terrible the language use is and I had to ask GPT to make it readable for me.

Please use a tool such as Grammarly or any number of AI tools to help write clear and understandable English.

I don't mean to discourage you, in fact, I think you're doing a great job. Half the battle is showing up, and you're already here and making the posts. Using those tools can help you to improve your writing skills by taking their corrections into consideration. It's how I continue to improve my own writing.

decker • May 9

And with using JavaScript and simple Objects you can do this a lot easier. No need for classes and inheritance and the like.

Clipso • May 13

Good job @kevin-uehara . amazing explanation :)

qwer • May 16

The explanation was nice, easy to understand

Antonio Martínez • May 16

The best explanation of this, to share with my partner's team. Thank you!!! :')

Cristian Fernando Dávila López • May 6

Thanks for the article.

However, I have a question. In the last principle (DIP), is not a better idea to use an Interface OrderRepository instead a class?

lombervid • May 8

In fact, afaik, that's what "depend on abstractions" actually means. You should depend on abstractions (interfaces, abstract classes) rather than a concrete implementation (a class).

What they explained I would say is more like Dependency Injection.

Владимир • May 22

Yes. The DIP principle hasn't a correct example and hasn't a correct explanation here

mehar sulaiman • May 12

Love to read