Why I Don't Teach SOLID
qualityisspeed.blogspot.com
Why I Don't Teach SOLID
1–6 of 6 posts
Re: Why I Don't Teach SOLID
#2I'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.
Re: Why I Don't Teach SOLID
#3Too 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.
Re: Why I Don't Teach SOLID
#4Too 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. Pleas…
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.
Re: Why I Don't Teach SOLID
#5Too 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. Pleas…
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.
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.
Re: Why I Don't Teach SOLID
#6Interesting 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.