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.