|
|
|
|
|
|
by collyw
2584 days ago
|
|
|
> I can identify after dozens of projects is just one: simplicity. Isn't that the point in SOLID though? To try and have some guiding principles for achieving simplicity. Certainly I have noticed that my own code hasn't been easy to understand a few months after writing it, one of the reasons used to be that I was trying to do too many things in one function / method. Of course having said that, everything is usually a trade off and overemphasizing things will probably be counterproductive. The other problem with ideas like SOLID, is that they tend to be so abstract that its difficult for them to be meaningful until you have enough experience to not really need them as guidelines. |
|
|
Probalby yes, but some things are an overkill.
"Single responsibility principle" is great, and should be practised.
"Open–closed principle" is also good. No problem here.
"Liskov substitution principle" sometimes feels like it should be more a language feature than an implementation one.
"Interface segregation principle" can be ok. The problem lays on when one creates interfaces for things that don't need one, because they are one of a kind. The code becomes confusing without any real gain.
"Dependency inversion principle" depends a bit on the previous point, because the links are through interfaces.
I've seen (and been charged to maintain) programs with too much ID (of SOLID) done, and it's chaotic.
It makes sense to do them in an enterprise size program, it makes sense to do them as a refactor when the program grows. But people applying principles willy-nilly on programs that do not need them (yet) make it too confusing for the ones after.