| > Isn't that the point in SOLID though? To try and have some guiding principles for achieving simplicity. 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. |