Hacker News new | past | comments | ask | show | jobs | submit login

I always took SOLID with a grain of salt, because they clearly started with the acronym and worked backwards to the constituent parts.

Is Liskov's substitution principal really one of the 5 most important pillars of software design, or is it just the best one that starts with an L?




One of Bob’s anecdotes is that it took him several years after he started teaching the SOLID principles to realize that they could be rearranged to form the word “solid.” So, no, I don’t think he started with the acronym.


The author mentions in the post, and I think I agree, that Liskov substitution is the most "principle-like" of the principles in that it's pretty much always applicable. If the child object can't be substituted for he parent object, then you haven't really extended it, you've just made another unrelated class that happens to share some code. Inheritance is probably the wrong pattern here, and if you call what you've done inheritance you're going to confuse the person who next touches this code.


I'm not arguing that it's not a real thing, but how often does the LSP come up in your day to day life as a programmer? I have not thought about this once, and I do not think there is a problem this has solved for me in 10 years.


It's not always easy to discover interface commonality. But when you do and it's a good abstraction, there are definitely benefits over scattering ifs and switches throughout your code.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: