Bad OO - Hal Helms Occasional Newsletter

[demnan]

Bad OO
I've been doing some in-depth consulting for a couple of companies recently. I enjoy these engagements: the companies tell me that they get a great deal from our work together, and I learn a lot. Lately, I've been learning how much misunderstanding there is over object oriented programming.

First, let me set the stage: the companies I've recently been involved with already have a successful application. In fact, these companies might be said to be victims of their own success. Their applications, built in the heat of battle, so to speak, were meant to meet immediate needs. As clients expressed new needs, new features were added on.

But with even more demands for more features, the application is stressed to the breaking point. The more useful they make the current application, the harder it becomes to keep the software viable. Of course clients (and managers) don't understand this. That's natural; they don't understand the process of creating software. But they have learned that if they add just a little more pressure, the requested feature generally becomes available. From their point of view, this process has workedin the past; why won't it continue to work in the future?

That's about the point I usually get asked for help. "We want to re-architect our software," they tell me, "and we hope that you can help." An examination of the present code usually isn't helpful-it just tells us what we already know: the software needs to be rewritten so that a new, firm foundation can support the product's continued success.

Often, these developers are already interested in object orientation. They have probably read some OO stuff and they have an idea that an OO redesign and reimplementation of their product will provide that new foundation. Usually, I begin my time with a primer on OO. We talk about encapsulation and abstraction; we work through type promotion and polymorphism; we differentiate between interface and implementation; we discuss design patterns and the UML. And then, they having armed themselves with new knowledge, we begin work on the project.

Now, had I hired a firm to film an ad for Hal Helms, Inc. consulting, we would see newly-empowered developers spontaneously coming up with elegant, flexible OO designs for their software. But reality is seldom so cooperative with the desires of marketers. Instead, what I see are developers who, not quite sure where and how to apply all those OO concepts, start with the thing they're most familiar with: the database.

Take the issue of customers and invoices as an example. After we conclude that both Customer and Invoice deserve their own components and that, further, the relationship between the two can be expressed as "customers have invoices", code like this appears as a method in the Customer class:

<cffunction name="getInvoices" access="public" returntype="query" output="false">
<cfargument name="customerID" type="numeric" required="true" />
<cfquery datasource="#request.dsn#" name="CustomerInvoices">
SELECT * FROM Invoices WHERE customerID = #arguments.customerID# ORDER BY date
</cfquery>
<cfreturn CustomerInvoices>
</cffunction>

When the developers realize how similar OO is to the code they've always written, they're greatly heartened: OO won't be so hard after all. And yet they'll still get the benefits of maintainability and reusability that OO is known for. The developers are in a festive mood-and I'm the grinch who is about to destroy their illusion that what they've written is object oriented.

But destroy it, I must because, clients are paying me to help them transform their development process. The reason "OO" seems so familiar to these developers is that it's not OO at all; it's just the same procedural code they've been doing all along "stuffed" into OO constructs. But, as Gerald Weinberg points out in his book, The Secrets of Consulting, if you use the same recipe, you'll get the same bread. Companies ask me to come in and help them create a new receipe that will better meet the demands of their business and give them the benefits of maintainability, robustness, and reusability. But stuffing procedural code into OO constructs (which the above code is a prime example of) won't provide any of these benefits. In fact, it's a "worst of both worlds" approach where we get the indirectness of OO code with the inflexibility of procedural code.

Over the next few weeks, I'm going to get into specifics about what OO is-and isn't-with a series of newsletters. I'll try to keep each one relatively short and I hope you'll find them helpful in gaining a fuller appreciation of object orientation. The next newsletter will be out later this week. In the meantime, ask yourself what makes the code I presented so very un-OO.


--------------------------------------------------------------------------------

Training news
On January 24-27, I'm holding a FastTrack to Fusebox 4.1 here in Atlanta. I usually only hold these 3 times a year, so if you want to master Fusebox, make plans for Atlanta!

On February 21-25, my Java for ColdFusion Programmers class goes to Las Vegas. With cheap flights and cheap room rates, Las Vegas is a tough venue to beat (in more ways than one, I suppose!)

On February 28-March 3, Ben Edwards and I do our FastTrack to Mach-II class, also in Vegas.

On March 7-11, I'm giving the first Creating .NET Web Applications with C# class, again in Vegas. As this is the first time I've given this class, there's special, reduced pricing on it.

Then on March 28-April 1 (no kidding!), I'm holding my OO Development with ColdFusion Components in Atlanta. This is a great class to take if you want to learn OO within the context of CFCs (rather than Java or C#).

For more info, please visit halhelms.com/training.