Stop the systematic abuse of object-oriented programming

Object-oriented programming (OOP) has become the dominant type of programming over the last 10 years or so; a major driver of this has been Java, VB.NET, and C#. But what I keep seeing more and more is that too many programmers using object-oriented languages really do not understand OOP.

A huge misunderstanding is the concept of encapsulation. Encapsulation is meant to hide the underlying implementation of a concept from the code that makes use of the object — not to expose it. The idea is that the consuming code does not need to know or care about the particular implementation “under the hood,” so it can be changed without affecting anything else. Encapsulation works hand-in-hand with polymorphism.

Between encapsulation and polymorphism, code can (and should) be extremely loosely coupled. But really it isn’t in many pieces of code that I have seen. Far too many objects end up simply being equivalent to a Pascal “type” structure, a strongly typed collection of other types, gathered in one spot for easy reference. Another fairly common misuse of OOP is to write “classes” that play out like hashtables of hashtables of hashtables. While that type of programming made sense in Perl for a variety of reasons (not the least of which is the lack of a comprehensible object system in Perl), it is not in the spirit of OOP.

Why are these techniques a problem? For one thing, they require too much knowledge by the consumer of the underlying functionality. The first example leads to these statements that look like this:

FooObject.Property.Item(Index).Method(Parameter 1, Parameter2).Property = BarObject.Method(Parameter 1).Property.ToKludgeObjectType()

If the consumer has no idea what any of those sub-properties, methods, and so on do, they cannot get too far using either of these classes. On top of that, by exposing so many of the internals to the consumer in what will need to be a full-access manner, the encapsulating object hands over full control. This can cause some real damage, particularly if those contained classes have properties or methods with negative consequences.

The second type that I describe typically looks something like this:

FooObject("Property").Item(Index).Method(Parameter 1, Parameter 2)("Property") = CType(BarObject.Method(Parameter 1).Item("Property"), KludgeObjectType)

Wow… what an utter disaster. Can you imagine working with this? The worst part is that, with all of those collection lookups, you can throw compile time checking out of the window. The person who writes this manages to combine a very dangerous aspect of dynamic languages (lack of compile time checking) with the worst of compiled languages (design time knowledge of types) into something that derives none of the benefits of either type of language. One “fat finger mistake” in all of those lookup values will compile just fine, but come run time, they will become errors of one sort or another. It would not be so bad if a simple mistake just lead to an outright exception like “Index out of range,” but if the mistake just happens to be purely logical (e.g., the item named does exist, but the wrong item was named), there is a solid chance that the code will keep running but with silent and hard-to-detect corruption of data and/or logic.

I know part of the problem here is simple laziness. I am guilty of it plenty of times. For me, what usually happens is that I am using an OO language for something that I really just need a procedural or mostly procedural language for. Let’s face it, not every application requires too much OO design — they really just need a way of quickly passing a bunch of loosely related data around. But these “shuttle classes” always seem to take on a life of their own, and the next thing you know, you are writing static/shared classes with static/shared members to process the data within the “shuttle classes.” Why? Because you really meant to be using Perl, Pascal, or maybe even Smalltalk or a simple shell script, not C++, Java, C#, or VB.NET (at least for this one part of the project, that is).

Folks, this is where the rubber stops meeting the road. Those earliest experiences with programming will always color our current thought process regarding programming. And nearly universally, we were introduced to programming with a procedural language or a very procedural use of a non-procedural language. Add to that the fact that contrary to popular belief, Java, VB.NET, and C# are not purely noun-oriented OO. After all, they have some primitive verbs in there. What we really just want to do sometimes is to extend the language itself (add new primitive verbs) –that is where those anti-OO static classes of static methods come from, and it is the only way we can really add a new verb to the language. Those pseudo-procedural-functions end up needing a ton of parameters passed to them (just like procedural code), since the data that they are working on is no longer included in the class that they are members of.

At the end of the day, this type of programming is indicative of one or more of the following things:

• The programmer was “born and bred” in a non-OO environment and is untrained in proper OO.
• The programmer does not feel like using the proper OO techniques for whatever reasons.
• The language being used is the wrong language for the job.

I think the last item is a lot more common than most of us care to admit. After all, we turned to OO to save us a lot of headaches, increase code reuse, etc. But none of the OO promises can be fulfilled when we treat an OO language like it is something that it is not. And if we are going to program away the benefits of OO, why bother using the languages?

I guess this is yet another reason why I am fairly pro on the .NET CLR (and would be on the JVM if Sun was more supportive of other languages). It is possible (in theory) to write the right code in the right languages. Sadly, the only two languages with massive support in .NET right now are the nearly identical twins, VB.NET and C#. It looks like the first language to get formal “kid brother” status is the functional language F#. IronRuby and IronPython are still “CodePlex cousins,” in which Microsoft might donate some time, server space, and documentation but little real support. Ruby is also attractive to me because it seems to blend procedural and OO code pretty well. I really, really need to try Ruby out.

The takeaway here is that you really need to get off the couch, learn proper OO, and use it correctly. Otherwise, you are hurting your own efficiency, writing slow code (all of those collection lookups and OO tree traversals are rather expensive!), and making your code difficult to maintain. If you still cannot figure out how to write what you need in an OO-friendly manner, you may need to think about switching languages.

J.Ja