In the realm of software development, a field known for its diverse and strongly held opinions, few practices have achieved consensus as a guarante...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for provding such a clear explantion to SOLID.
By the way, there is a small error in the article. The actual result and expected result in the following code snippet used in the LSP section should be swapped.
console.log(square.getArea()); //Expected: 50, Got: 100 (X)should be:
console.log(square.getArea()); //Expected: 100, Got: 50 (X)Thanks for the comment Matthew!
The mentioned code block was meant to describe the Lisokv's principle violation, where increasing the square's width using
increaseRectangleWidth()unexpectedly affects both dimensions (width & height) due to theSquareclass setter, eventually leading to an area of100instead of50.increaseRectangleWidth()by its own nature should increase only the width of the provided rectangle, however all the square's sides were increased, leading to the actual violation.I really enjoyed catching up on the SOLID principles. Thanks!
Glad to hear Nathan, thanks for the feedback!
Do you have any linting solution to catch the SOLID violations automatically ?
From my experience that depends of language you are using
but any static analyzer would be work for you
Here are a list per language github.com/awesome-security/awesom...
Nice Read
Thanks for the feedback!
Great article! It is always more understandable and beneficial when the explanation has examples alongside the theory. :)
Thanks! Glad you liked it :)
Great article about what is arguably one of the most useful principles in software development.
Thanks for the feedback!
Single reason to change. Meaning that the product manager you initially presented is perfectly fine unless your analysis predicts high frequency changes form the start.
Otherwise you are looking at meaningless over engineering which is probably the worst you can do at the start.