OO is Irrelevant! 4
This got me to thinking because the SOLID principles are not about writing OO software. What follows is my original response, but it seemed to warrant a blog entry.One can comment critically on the “Employee” class example, though. Frankly, it IS bureaucratic. So either it’s a bad example and you have mispresented your principles, or Joel is right.
Since no one has the authority to define OO, I’ll even venture to say that “Employee” is not OO.
Something being OO or not OO is irrelevant. The original point of OO was an experiment in adding a new kind of scope to see what happens (go back to mid to late 60’s). Then it was to make it easier for kids to program (I’m thinking of Ala Kay and Smalltalk in the very early 70’s). Eventually it was to make more maintainable code.
Ultimately, doing X to get Y often promotes X as the original goal. We do OO to make maintainable code so we can deliver faster and respond to change. This eventually becomes we do OO and not doing is OO is bad.
Same can be said for agile, TDD, scrum, XP, pretty much anything …
There was another “worthy” comment from another poster:There is no executive summary that explains the SOLID principles well enough that you can comment on them critically.
The SOLID principles are about a goal. That goal is understanding what makes code better or harder to maintain. They come from several people. Bob wrote some of them, he collected others and he’s got even more (component coupling and cohesion principles, e.g. Reuse/Release Equivalence Principle). He experienced pain developing large systems in many languages including C and C++. These principles are meant to make our life easier, not to develop OO software. They do suggest using tools available in OO to enable building better software (e.g., the OCP and polymorphism – not just method overloading but selecting a method from message based on type of the receiver done by class-based OO languages, arguably the manifestation of polymorphism in prototype-based languages like JavaScript and self, are different mechanisms to accomplish the same effect).
If code is hard to work with, the SOLID principles are one way to identify problems. Using Martin’s code smells is another. You can go back to good old coupling and cohesion, code analysis tools, etc.
In the end, suggesting that OO is a goal is equivalent to creating UML diagrams because “the process” says so. It is a form of cargo culting. It just furthers the point that critiquing based on an executive summary is a problem.
One might argue that because something is hard to understand, therefore it is of little use. I have two responses to this:- I don’t think they are hard. They do take effort and lots of experience to really internalize, but most things worth learning are like that.
- An effective practitioner of any complex profession eventually has internalized thousands and thousands of rules, guidelines and principles such that s/he just “sees” (or in Fowler’s case “smells”) problems not seen by the novice. The SOLID principles are a mix of beginning, intermediate and ancillary rules that fit into the toolbox of effective practitioners.
Let the flames continue!
I hadn’t ever connected it with OO before but I’ve long felt that the important take away from any Agile methodology wasn’t the principles and cute one liners but the problems that the principles are intended to address. Whether you like the idea of onsite customer or not, it’s hard to argue that you’re better off if the customer and the technical team can’t talk to one another in some way.
Every critique i’ve read of XP has focused on “Principle X doesn’t work so lets do what we’ve always done but do it better” and (to me) thats not the point. The point is that there is a fundamental disconnect between process and reality and the old ways are never going to work unless we address that disconnect.
Which just leaves me with one thought. If OO and XP/Agile are related in that they’re focused on to the detriment of the problems they’re attempting to fix, does this mean we should preparing for a flood of technologies “that support” XP and Agile , talks and courses about the XP/Agile “paradigm” and are we ready to laugh at them like we maybe should have laughed at the cultists all those many years ago.
Jon,
I don’t think that …The people who gave us OO, XP, Agile, Scrum, ... understood that the practices and done for a reason. They were not focused to the detriment of their what they were trying to do. They had success, they described it and why the practices were important.
Unfortunately, I think it is a human trait to replace doing X for Y with doing X because X is good.
It goes something like this:In fact, this mistake is actually the error of implication.
If x implies y (x -> y), and X is (use OO) and y is (because it improves maintainability). Given x implies y, we cannot say anything about !x. Doing so is the error of implication. A classical logical problem taught in discrete mathematics.
So not doing OO does not necessarily lead to non-maintainable code.
Unfortunately, someone learns about OO, likes it, forgets the reasons and then they’ve drunk the cool aid. At that point, they don’t know why they are doing OO, just that it is good. And here’s what happens:Again, I think this is human nature. I don’t think it has anything to do with OO, Scrum, Agile, XP, ... I think it has to do with the fact that most people do not have mad abstraction skills.
This kind of argument (do X because X is good) is zealotry.
My meta-process is “do what seems to make sense.”
For example, if I’m in an organization and they follow UP and use UML, then unless they paid me to teach them XP, I should learn to work first in their way, find inefficiencies, point them out and gradually migrate them to more efficient behaviors.
So while my preference is not not follow the UP, I’ll do if the context suggests it. I can say the same thing about pair programming, tdd, etc.
I’d prefer to practice tdd with pair partners, and if I can get it great! If not, can I still make a positive impact? If so great, if not, time to move on.
When I teach a TDD class, I suggest to the students to pair program. However, I don’t force it on them. I tell them that they will probably learn more and move faster, but it is their choice. I do make it clear, however, that if everybody works alone, then the class as a whole will probably move slower since I have effectively twice the number of possible problems that can happen when they do not pair.
Brett, good article!
Absolutely. I didn’t intend to imply otherwise. I’d lay odds that if you look back at the publications of the people who gave us OO you’d see the same. It’s not the primogenitors who become cultists. The Kool Aid drinkers that I worry for are the next generation of programmers who “grow up” learning that !x is bad without absorbing why.