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...
For further actions, you may consider blocking this person and/or reporting abuse
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)
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:
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 :
If you do that the program could be broken.
Any way, thank you for your explanation this was just to complete your explanation.
And don't forget about principles:
Sometimes they are very important too 👍
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.
Hi Kevin Toshihiro Uehara,
Your tips are very useful
Thanks for sharing
Really great article, simple and understandable.
the tips is so cool.
but .. a lot of spelling errors. (my english is not so good)
The best explanation of this, to share with my partner's team. Thank you!!! :')
Good job @kevin-uehara . amazing explanation :)
Thanks!
Hi Kevin.
Another BrazDev here!
I've fascinating with your courage in writing a article in plain english!
Thanks for encouraging me as well!
Tks Kevin.
The difficult thing is to be simple!
Great article.
Easy to understand!
The examples make the concepts very easy to understand.
Thank you for all great posts !
Thank you for simplifying the understanding of SOLID principles.
neat explain ,thank you , waiting for more articles such that .
Nice one. Its so easy to understand.
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?
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.
Yes. The DIP principle hasn't a correct example and hasn't a correct explanation here
Love to read
The explanation was nice, easy to understand
And with using JavaScript and simple Objects you can do this a lot easier. No need for classes and inheritance and the like.
very helpful
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.