A Very Poor Object Model Is Really No Object Model At All

First let me say that I’ve met Keith personally, and he’s a really cool guy.  Cool enough in fact, that he’s on my RSS subscription list. I’d consider him a friend.  :-)

This is my response to his recent post, How To Not Screw Up Your Application Object Model.  I’ll also point to Arnon’s reaction.

Exhibit A:

This is a very, very poor object model.  It’s a very poor object model even if it perfectly represents the business requirements. I’m going to nickname this the “college freshman” object model, and we all know how useful college freshmen are in the real world (and just how much they have to learn before they become useful).  In short, never do this–again, even if it perfectly represents your business problem (which it won’t).

I’ll also repeat what Arnon said.  In a nutshell, don’t use a bulldozer where a simple shovel will do.  Building an app for a vet is a good candidate for CRUD and Microsoft Access.  Don’t overcomplicate your solution.

Also, if you are developing outside the guidance and expertise of the customer, you greatly increase your chances of failure and waste.  Don’t do that.  It’s irresponsible and foolish.

I’d also like to point out that this object model is driven by the C++ object model thinking of yesterday.  We’ve learned a lot since the 70′s and 80′s, and that includes how to do objects.

I’ll point out two very important facts that are rather obvious:

  • We don’t have multiple inheritance in C# or VB.NET.  That greatly affects how we do OOP.
  • Inheritance is a very fragile.  99% of the time it’s the wrong tool to use (as this diagram elegantly illustrates)

Luckily, we’ve learned a lot in the past 10 years and evolved our design techniques since then.

Inheritance is the old stuff.  Composition is the new stuff.  We’ve learned about the fragile base class problem and moved on.  A solution using composition (instead of inheritance) yields way more flexibility and is much more resilient to change (when used properly).  Where inheritance represents the relationship with the most coupling between two classes, composition allows us to freely decouple two (or more) classes.

Is bad OOP really bad OOP or is it just not OOP at all?

If you’ve implemented a deep type hierarchy in your .NET app while trying to build an “object model”, you’ve sorely misunderstood how to apply OOP in .NET.

In conclusion, I’d like to challenge Keith to write a new post on the following:

The reason is because we have been beat to death with OOP principles.

I’d be curious as to what principles you are referring to.  I get the feeling that the OOP principles you are referring to are completely different from the ones I follow.  I’d love to carry this discussion further.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to A Very Poor Object Model Is Really No Object Model At All

  1. Dude, if your object models aren’t AT LEAST 10 levels deep then you aren’t a hardcore OO Programmer.

    Real Programmers Do it DEEP.

  2. Evan says:

    @Ben

    It’s a good thing I wasn’t drinking anything when I read your comment. I would have sprayed it everywhere.

  3. steve wilson says:

    Can we have a composition example, be nice to see how you would achieve the above model using the technique you suggest

  4. Keith Elder says:

    Even,

    For clarification yes, I’d consider you a friend as well. I didn’t want to admit that publicly but you forced my hand (kidding!).

    I think you answered your own question about “beat to death” with the way you referred to the sample object model as a “college freshman object model”. That was the EXACT point I was going for when I built that crazy “educational” model. While the people I have been talking to aren’t freshmen in college, I’ve seem them still trying to apply what they thought would be the “perfect object model” to an application. This is the point of the post to get them to not think like that just because their professor put it on a test.

    The point Evan is it isn’t about how you and I follow OOP principles. The point of this whole excercise is to show people these things:

    1. Don’t build an object model before you know the requirements.
    2. Know the business requirements.

    If you wanna chat more, I’m on MSN anytime. http://keithelder.net/about.aspx.

    Hope that helps.

    -Keith

  5. good post!

    I agree with Steve that it would probably be good measure to show the domain model above with a proper architecture using composition instead of inheritance. I think that would be a good followup.

  6. Colin Jack says:

    Good post and related posts. As you say composition is where its at in general, a little inheritance can be fine but still way overused.

    Interesting stuff.

  7. Nathan Zook says:

    That example is EXACTLY the sort of thing that convinced me that OOP lacked an ‘s’. Until I me ruby.

    To drive the point about bulldozers vs shovels: NOT EVERY APPLICATION SHOULD BE DONE IN OO. SOMETIMES “C” IS WHAT YOU NEED!!

    Of course, if you are doing microprocessor validation, asm is what you need, so you better develop the tools to do it well.