Designing object-oriented software is hard

March 30, 2009 · 11 Comments

Ben Nadel had a bit of a "crisis of faith" last week over his ability to learn OOP the "right" way. He's highlighted a problem most people have coming to OO these days: in their search for the One True Way(tm), they are overwhelmed and can feel like failures. It can be a long, hard road. In a comment on his blog, I recommended everyone read the first two paragraphs of the "Gang of Four" Design Patterns book because it really sets this in context. I'm going to reproduce those first two paragraphs here to get you thinking. I highly recommend buying and reading the book.

Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. You must find pertinent objects, factor them into classes at the right granularity, define class interfaces and inherited hierarchies, and establish key relationships among them. Your design should be specific to the problem at hand but also general enough to address future problems and requirements. You also want to avoid redesign, or at least minimize it. Experienced object-oriented designers will tell you that a reusable and flexible design is difficult if not impossible to get "right" the first time. Before a design is finished, they usually try to reuse it several times, modifying it each time. Yet experienced object-oriented designers do make good designs. Meanwhile new designers are overwhelmed by the options available and tend to fall back on non-object-oriented techniques they've used before. It takes a long time for novices to learn what good object-oriented design is all about. Experienced designers evidently know something inexperienced ones don't. What is it?

Read it over and over again to make sure you're taking it all in. This stuff is hard and you'll be overwhelmed at the beginning. It takes a lot of time and experience to get "good" and even the experts almost never get it "right" the first time, or even the first few times. Don't be discouraged but be realistic: don't expect OO to be a quick win. It's a process, a journey. I'd been doing OO for about three years before that book first appeared - imagine how frustrating those first three years were! Even after the book appeared, imagine how long it took people to come to terms with what the authors were saying and how much longer it took most people to take the contents of the book onboard! "Design Patterns" - Gamma, Helms, Johnson, Vlissides - ISBN 0201633612

View count: 2738

Tags: architecture · coldfusion · programming

11 responses so far ↓

1 Ben Nadel // Mar 30, 2009 at 10:11 AM

I certainly won't abandon my pursuit of a better understanding of OO. I think a lot of my concern came out of people berating things like "Anemic Domain Model" and thick service objects. It filled with a fear that doing down that route was wrong. Not to say that there aren't down sides to it, but I think the reason that so many people *do* go that way is because it does add a lot of value to them at the time.

Not to say that I want to go down that way, but that I need to dump this fear based thinking.
2 Sean Corfield // Mar 30, 2009 at 10:30 AM

I think the anemic domain model tends to appear because folks new to OO have a hard time figuring out where business logic goes (which this recent discussion about where business rules and policies should be modeled has highlighted). It's the "hard" part of OO design, no doubt about that!
3 Michael Long // Mar 30, 2009 at 12:51 PM

Design Patterns (specifically the gang of four book) came about as a way to recognize and consider various ways of structuring applications. Each pattern mentioned has advantages AND disadvantages.

Where most developers get into trouble (IMHO) is that too many people have gone from treating patterns as food for thought to the software equivalent of tablets handed down from heaven, whose rules, etched in stone, must be followed to the letter at all costs.

They're not rules, they're more like guidelines... (grin)

The second thing is that too many people also believe that the holy grail of OOD lies in reuse.

It's not. Reuse is an important consideration, but above all OOD is simply a way to structure and incrementally built complex applications, as well as to "black box" various parts of the application from one another so that changes in module "A" won't break something in module "X".

The third thing to remember is that the ultimate goal of OOD isn't to do OOD simply for the sake of doing OOD. It's to quickly and easily create relatively bug-free applications for people to use.
4 Sean Corfield // Mar 30, 2009 at 1:04 PM

@Michael, good points.

Your comment about reuse is particularly important since the vast majority of code we write is custom code and is never going to be reused. In many ways, OO is "just" an evolution of modular design, albeit on a finer-grained level, and an attempt to make software better "match" the domain that we are trying to work within.

It's also why, for example, BDD has such an emphasis on using terms from the business domain rather than lower-level terms from the (planned) implementation that is more common in TDD - even tho' both approaches are contingent on a tightly modular and generally OO mindset.

And, yes, each design pattern has DISadvantages as well as advantages. My point about tradeoffs and one that is continually omitted in most discussions (in the CF community).
5 ryan // Mar 30, 2009 at 2:07 PM

still is one of the greatest books ever written on the subject... [*i'll wave my beer mug at that!]
6 Adam Ness` // Mar 30, 2009 at 2:49 PM

While "Anemic Domain Models" can be bad, they are a good starting place. I tend to see OO as an "Organic" model. If you're following good design patterns, it becomes possible, even easy to move chunks around and redraw the boundaries around objects when you need to.

I tend to take the Agile maxim of "Engineer the system for what you need now." to heart. Object Oriented development works great with that, because it breaks the problem up into smaller chunks, and if I need to later roll those chunks together, or split them apart, OO gives you models/tools to use to do that splitting and combining. Far too often, OO education though (at least in ColdFusion) is pitched in terms of "Use Gateways, Beans, and DAOs and MVC and voila! You're an OO developer."

OO is a lot more than just learning 3 or 4 patterns and calling it good. OO is really based on starting to think of your software as a system, composed of smaller systems, and thinking about how those systems interact with eachother. It's about drawing lines around piles of complexity, and trying to encapsulate that complexity. It's not a formula that can be taught, but rather a set of guidelines you can apply, which make code smaller, and easier to change, and more interesting to read.
7 John Farrar // Mar 31, 2009 at 5:19 AM

OO is a funny thing if you have a good sense of humor. It is powerful and flexable. Yet it is limited. It could be said that the most dominate trait of OO is that one size does not fit all. Now by size I am talking about 'Design Patterns'. @Adam is right about thinking about software as systems. The body has systems also... common interfaces and unique functions. When we code we are designing systems. In we are building something big, REAL BIG then not using objects means there are so many unique moving parts the project is either likely to fail or be nearly impossible to maintain in a stable fashion. If on the other hand we build with good foundations to how we do OO that are solid but applied principles rather than religious dictates it will start to make more sense. :) You have to grow as @Sean said. There are also those rare times when someone who doesn't know all the design patters, who is learning as he is able, creates or applies things in new and creative ways. This means that the time it takes to master is not always a negative thing. There is good that comes from it.
8 Rohit Channazhi // Apr 1, 2009 at 1:50 AM

The reusability is as good as the original usability was. To start thinking and demarcating bits of code into reusable chunks of classes and objects is truly an art form though. I've to keep track of so many things like commenting, optimizing for performance, syntax related issues and its easy to lose track of the main reason why OOP was designed for.
9 james // May 22, 2009 at 6:54 AM

OO design is an art form. For me, one of the biggest joys of my job is looking critically at the code i have written and seeing another, *better way to organize it. It seems that each time i descend into the model of applications, and look critically at the design of the objects, i see things a little differently. I put a high value on the maintainability of the code, by that i mean when someone looks at it, besides me, can they figure things out relatively easily. A smart fellow once said "the greatest threat to software is complexity". By following the design patterns mentioned in this thread, services, gateways, daos, beans, mvc, we can predict where a lot of the code will be, but there is no *one way that works best in every situation.

Right now, i'm wrestling with the boated service and anemic bean syndrome. Where is the best place to put bus. logic that deals with the bean? Too much in the service, not enough in the bean itself. Guidelines, not rules....ah yes....guidelines
10 Nathan Stanford II // Oct 2, 2010 at 12:04 PM

Sorry to bring up an old blog post...but I thoroughly enjoyed this post. I see what your saying and the comments are even better. Also, I thought you would like this Sean, I had to read this for a Systems Analysis and Design class :). I found it cool that my teacher was sending us to a Coldfusion blog about OO when the school teaches PHP. Love some Coldfusion :)
11 Sean Corfield // Oct 3, 2010 at 7:47 PM

@Nathan, that is pretty ironic! I'm flattered.

An Architect's View

CFML, Clojure, Software Design, Frameworks and more...