New Ways to Consider Object Oriented Design

What's that? The Internet clamors for more on how learning UML has caused me to reconsider my object oriented designs? Fine, if I must!

Like I said, I'm reading Martin Fowler's book on UML, UML Distilled. In it, I found a fascinating paragraph related to OO design.

"In general, the OO style is to use a lot of little objects with a lot of little methods that give us a lot of plug points for overriding and variation. This style is very confusing to people used to long procedures; indeed this change is the heart of the paradigm shift of object orientation. It's something that's very difficult to teach. It seems that the only way to really understand it is to work in an OO environment with strongly distributed control for a while. Many people then say they get a sudden 'aha' when the style makes sense. At this point, their brains have been rewired, and they start thinking that decentralized control is actually easier." Fowler, page 56 of UML Distilled.

There's all kinds of good stuff in there, although the phrase "paradigm shift" makes me want to karate chop a puppy. As much as I hate the terminology, the paradigm shift is the part that interests me the most in that selection. Fowler doesn't write it explicitly, but what I glean from that paragraph is that another way to view object oriented design is to see it as procedure disoriented design. That is to say, OO is as much about embracing objects as it is scuttling the notion of designing through a bunch of linear procedures.

Does that contribute anything to my understanding of OO? I think so, because "procedure disoriented" explains what the objects allow you to do. With objects, you design as if the sequence of your code doesn't matter. Rather than a bunch of steps that must be performed linearly in a monolithic procedure, you divide the work into as many autonomous entities as possible. With this idea, lengthy procedures fly out the window entirely, at least until you start utilizing your objects.

Also, "procedure disoriented" helps to enforce a good way of using objects. It's not a real "Stop the presses!" admission, but I've certainly been guilty of using objects as glorified procedures. In these instances, I would have a central object that shuttled between all of the other objects, getting data and doing most of the algorithmic work. Fetch me my dunce cap, because that's not what objects are for! Good OO is about distribution, not centralization! Parts, not procedures! (If we ever have a developer sit-in to protest something, I nominate the preceding statement for what we chant when they turn the hoses on us. It's just catchy.)

So, will we go through all of the textbooks now and change OO to OOPD? Hell no, it doesn't sound nearly as cool. But maybe one day you'll hear someone talking about objects and procedures, and a tear will come to your eye as you think, "I remember when some jack ass on the internet was talking about that."

Object Oriented Design and Learning

Right now, I'm reading Martin Fowler's book, UML Distilled, as we begin to gear up at work for the design phase for a new product. (As a corollary, any computer book that's only 150 pages long gets the Powell seal of approval. The 1,200 page tomes force those of us with time constraints to read like Johnny 5 in Short Circuit!) For the unaware, UML is a standard for graphically modelling an application's design. You analyze your design, annotate it up with UML, and the end result is something that looks like a Pac-Man level. Pretty cool stuff, but a lot of the coolness factor has nothing to do with UML itself.

One thing that interests me with software development is the consequences of learning a new skill. It seems that often, learning how to utilize a new process can cause me to look at my entire development methodology in a new way. UML is a good example of this. All I've done is learn a new way to graph things, but learning this new method has caused me to reevaluate every object-oriented design I've ever devised. Why? I have a new method of visualizing all of those designs, and this new method happens to show me some things I never considered previously.

Trust me, this discovery has rocked the world of one Cody Wayne Maxwell Powell. In some of the more harrowing moments, tears were shed and insults were hurled at my cat. (Octopussy, I apologize!) Nevertheless, I view this as a good thing. The only way to verify you're thinking correctly is to subject that line of thought to as many forms of analysis as possible. Luckily, the arena of software development moves so quickly, these new skills and methods pop up regularly. All we have to do is pay attention to these new methods and give them a shot. In essence, that is the point of this site: ruminating on new ideas, often to embarrassing results.

Leave it to Ferris Bueller to summarize in a sentence what it took me three paragraphs to get across: "Life moves pretty fast; if you don't stop and take a look around once in a while, you could miss it." If I accomplish nothing else, let us hope this site will plant a seed for a sequel, featuring Ferris and Cameron's zany UML hijinks.