Is this Object Oriented (Enough)?

When people look at my code I get a wide range of responses from incredulous to dismissive to excited. I imagine it's not much different for most advanced developers. As I imagine is the case with many skills, although the expert certainly knows more than the novice, experts often disagree. Why? Well because experts "know better".

A novice looks at a piece of code and generally speaking they can't really tell the difference between code that's "elegant" and code that in spite of "getting the job done" will become problematic later. It's the same with a piece of sheet music or an architectural blueprint or whatever... any skill you haven't thoroughly developed leaves you with a knowledge gap where you can't really discern the subtle differences between good and not so good work. And although gaining skill allows you to become more discerning, it often leads to some rather wide disparities of opinion about what constitutes good or not so good work.

In the past week or two the CF community blog-o-sphere has been talking about what it means to be OO or what it means to be good OO or to "simulate OO". Ben Nadel expressed some frustrations about reading articles about accessors and mutators. We've heard more of the tired, old and completely invalid arguments about ColdFusion not being a "true" OO language because of things like the lack of abstract classes or the fact that a CF object isn't equally as efficient as a Java object (which lacks a lot of the behavior of a CF object). And of course just today Pete Bell and Brian Rinaldi published a short debate about the use of OO techniques.

I'm not going to address the notion that we're "simulating OO" instead of writing OO code when we work in ColdFusion, because frankly, those arguments are stupid, based on misconceptions of OO and not worthy of your time. 'Nuff said.

But in bringing up the previous blog posts, what I'd like to point out is that I think quite often we ask this question: "is this OO?" We may ask it in various different ways. Is this a good OO technique? Is this the way OO applications are written? etc. But the basic question is the same. Is this OO? Or is it "OO enough"?

And I'm going to make the claim that this question, however it's phrased, "is this OO", is not only completely useless, but it's actually counter-productive.

It's seductive, that's for sure... Because it's a very simple question, and as humans we like simple. Even programmers as much as we like complexity still gravitate toward simple things. Sometimes we call them "elegant". The problem with "is this OO?" is that it's far too simple. It makes the rather bold assumption that either the questioner or the person asked has some magical definition of what "OO" is... or worse of what "good OO" is. We don't.

Part of the problem is that the definition of OO is pretty well known and yet especially in the ColdFusion community its nearly impossible to get people to stop attributing new extra requirements on the definition of OO. Witness comments about ColdFusion not being OO because it doesn't have abstract classes, or previously because it didn't have interfaces. Neither of those two things make it a "procedural language".

I've seen this apply to experts as well as novices. Several years ago I saw some notes from a conference presentation in which Jeff Peters (a member of Team Fusebox) talked about various frameworks. He was kind enough to mention the onTap framework and yet in spite of the fact that it already included a small library of CFCs and a variety of tools to help manage them (including workarounds for the lack of application-specific mappings), described it as "a procedural approach". This was shortly after the initial release of Mach-II and at the time as best I could tell, his reason for judging the onTap framework as "a procedural approach", centered around the fact that it didn't have a config dialect in XML! Which of course has zero to do with what is or isn't OO, as has been made abundantly clear in the intervening years and recent releases of Fusebox and ColdBox.

I mention Jeff Peters here by name not to "call him out" but rather merely to point out the fact that being an expert doesn't make someone immune to poor judgment. I consider Jeff to be both skilled and knowledgeable. That doesn't change the fact that we're all still human and that means we're all still subject to just that kind of biased assessment.

So right up front, asking "is this OO" is very likely to lead to people giving the answer "no", when the correct answer is "yes" because they've bogusly attributed some new property as a requirement for the definition of OO.

At this point the question "is this OO" becomes one of a religious nature, not of a technical nature. Because each individual's definition of what is or isn't OO depends so heavily on their own personal interpretation of the literature. And because so many people will simply look for excuses to claim that something is "not OO" just because they enjoy shooting things down. We may as well ask "what would Jesus do?" ... I need to persist my data in a database ... well Jesus obviously would use an ORM... a Divine, OO ORM tool, written in Java!

Sorry... that's a useless answer... it's a useless answer because it's a useless question.

So if "is this OO?" isn't a useful question, then what is?

Questions that are useful:

1. Is this highly cohesive?
1. How many things does this function/method do?

   if this function or method handles both user authentication and changing a user's password, then DING DING DING raise the red flags, it's not cohesive

2. How many things does this object do?

   I don't have any hard and fast rules for this one - sorry

2. Is this well encapsulated?
1. How many *other* files would I need to change if I were to change the behavior of this function or method?

   the ideal answer here is zero, that's what you should strive for - one or two or even three may be okay... FOURTEEN (as was the case on one of my recent jobs) is a disgrace and you should hang your head in shame

2. How easy would it be to extend this CFC to change its behavior to do something else? How many functions/methods would I need to overwrite to accomplish that task?

   again, I don't have any hard and fast rules here, but it's a useful question

Stop yourself when you're about to ask "is this OO" and ask yourself these questions a few times instead. What you may be surprised to discover is that asking yourself about the specific goals of OOP like cohesion and encapsulation may result in different answers than asking "is this OO?" You may find that things for which you would normally answer "yes, this is OO" turn out to be very poor examples of meeting these goals. Or vice versa, that things for which you might normally nay-say and say "no, that's not OO" actually meet the goals of OOP quite well.

So that's it for today... I realize this has been something of a rant on my part. ;) But I hope that some of you find this article useful. And if you have any suggestions of other useful questions to ask, please do share them. :)