DEV Community

Cover image for SOLID - The Simple Way To Understand

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
Collapse
 
yannschepens profile image
Yann Schepens • • 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;
}
Enter fullscreen mode Exit fullscreen mode

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;
}
Enter fullscreen mode Exit fullscreen mode

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");
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

If you do that the program could be broken.

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

Collapse
 
devh0us3 profile image
Alex P •

And don't forget about principles:

  • DRY – do not repeat yourself
  • WET – write everything twice

Sometimes they are very important too 👍

Collapse
 
jon117 profile image
Jon-117 •

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.

Collapse
 
jangelodev profile image
João Angelo •

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

Collapse
 
wahidnabi_70 profile image
wahid-Nabi •

Really great article, simple and understandable.

Collapse
 
alexlevn profile image
Alex Lee •

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

Collapse
 
messinger profile image
Antonio Martínez •

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

Collapse
 
clipso profile image
Clipso •

Good job @kevin-uehara . amazing explanation :)

Collapse
 
w0lf46 profile image
Lucas Palhano •

Thanks!

Collapse
 
gabrielsimas profile image
Gabriel Simas •

Hi Kevin.
Another BrazDev here!

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

Thanks for encouraging me as well!

Collapse
 
hectorlaris profile image
Héctor Serrano •

Tks Kevin.
The difficult thing is to be simple!

Collapse
 
akashj2342 profile image
Akash •

Great article.
Easy to understand!

Collapse
 
msindev profile image
Mohit Singh •

The examples make the concepts very easy to understand.

Collapse
 
kishan_vp_66a386dcc65935 profile image
Kishan V P •

Thank you for all great posts !

Collapse
 
ibrito profile image
isaias •

Thank you for simplifying the understanding of SOLID principles.

Collapse
 
ahmedalmogy profile image
Ahmedalmogy •

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

Collapse
 
masteing_the_code profile image
Joel Jose •

Nice one. Its so easy to understand.

Collapse
 
krif profile image
Cristian Fernando Dávila López •

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?

Collapse
 
lombervid profile image
lombervid •

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.

Collapse
 
beryozavv profile image
Владимир •

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

Collapse
 
meharsuleiman profile image
mehar sulaiman •

Love to read

Collapse
 
sdotpython profile image
qwer •

The explanation was nice, easy to understand

Collapse
 
decker67 profile image
decker •

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

Collapse
 
syedgaian profile image
syedgaian •

very helpful

Collapse
 
stefano_barzaghi_6db3fa59 profile image
Stefano Barzaghi •

Thanks for the post.
I don't reckon the example for LSP is correct. It regards only the proper use of inheritance but doesn't explain what the principle states.