
Why I Don't Teach SOLID - phiggy
http://qualityisspeed.blogspot.com/2014/08/why-i-dont-teach-solid.html
======
johan_larson
I've been rather skeptical of the Java community's rush toward inversion of
control and dependency inversion, myself. It spawns a mass of interfaces, the
vast majority of which have only one implementation. So you are usually adding
a layer of abstraction without accomplishing anything.

The approach I favor is to identify seams and abstraction boundaries at a
higher level, corresponding to larger units of functionality. Then carefully
define interfaces between these larger units, and build mocks for them for
testability. But having defined interfaces for every class, or even close to
every class, is overkill.

------
je42
Too me this sounds he came back from over-using the "hammer".

However, I really like his article because he applies some prioritisation
which of the concepts are more important. (i.e. reducing dependencies and SRP
).

However, the other concepts of SOLID are still good to know and to apply. You
should just not apply them as a only resolution to your problem.

And you will get into deep trouble if you violate LSP. Please don't.

I think in general you should not use depth-first to search for a tool to
solve a problem. \- Mix in some reasonable breadth first search (i.e. try a
few other tools that could fit the problem. ). \- Then look at the space, pick
the best solution found so far, apply it, reevaluate. \- If necessary refactor
after learning more.

Also, i believe one of the most important problem resolution strategies that
is missing: is to reformulate the problem into a problem that is easier to
handle.

~~~
delinquentme
LSP: two users: an admin, and a common user. _CLEARLY_ we can see these two
_should not_ have the same functionality, thus a GOOD design pattern. Yet
clearly in violation of LSP. Esplain please.

~~~
erdeszt
The admin user don't necessarily have to inherit from the common user. They
can extend the same base class or implement the same interface. Afaik LSP
doesn't say anything about the abstract methods(it doesn't make sense to call
them on the base class anyway). So you put the common methods(e.g. getName) in
the base class, you won't break those in the different roles, and make the
role dependent methods abstract.

------
ryanobjc
Interesting post, and I think he is on to something.

But I really wish we got an alternative with the crap-fest. Otherwise you are
just left with a 'ugh now what'.

Personally, I still like the guidelines in "Growing Object Oriented Systems".
The focus on the caller of your code helps you reduce complexity in your API.
It helps you build components from the viewpoint of the caller (aka user).

The biggest thing missing in software engineering right now is empathy for the
user. Let's fix it.

