Search | Blog | Contact

OO is Irrelevant! 33

Posted by Brett Schuchert Sun, 22 Feb 2009 21:59:00 GMT

On one of Bob’s recent blogs, way near the bottom of the commens, was the following “argument”:

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.

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.

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:
  1. 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.
  2. 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!