May 4, 2008
@ 10:05 PM
Comments [4]
OOPs - an example of misusing the term OOP
I saw a post (via Dzone) by Keith Elder called  "How to not screw up your application object model - Don't go all OOP on me!"
Its a long read, so I'll give you the skinny. Keith tries to make his point by an example. He designs an elaborate initial object model for a veterinary clinic (IPet, pet, cat, dog, spaniel, owner, address, work address ..), then takes the search screen from a real vet. app, maps the model to the information needed for that screen and explain that the initial model sucks and that that particular screen needs two UI objects (search and searchresults) that would better handle the problem.
He sums the post with
"The big takeaway from this litany of verbal spillage is when you design
applications you have to know how the end-user is going to use the
application and what the business requirements are.  Sitting down and
building an elaborate object model, while really fun and educational,
it is a big waste of time.  Don't do it.  Sit down and ask questions so
the behavior and business requirements can be accounted for.  Whether
you are using CSLA.Net or not the same thoughts must go into building
the application.  I hope this helps cements these concepts because I
know there is a large amount of disconnect with this out there among
developers who think everything is a perfect object graph like they
learned it in school. "

There's nothing really wrong in the conclusion on its own but in the light of the post itself there are few things to notice
  1. The "elaborate object model" Keith talks about has nothing to do with OOP.
  2. Keith just drafts an "elaborate object model" but fails to note that it is a "Problem Domain Object Model" (PDOM) and a bad one at that (since it wasn't built with a domain expert involvement). The role of a PDOM is to form an initial working vocabulary with domain experts. It is usually a big mistake to use it as a foundation for development
  3. Even as a PDOM and even considering it was built for the sake of argument, it still doesn't make sense to create a class for each type of dog. When you create a sub-class you need to have a new behavior not a different value in a property.
  4. The example of the client side objects which do not match business side objects doesn't prove anything. client object (esp. search dialogs) tend to cross or aggregate domain boundaries. You can still have a meaningful OO domain model running in a backend.
  5. The fact that the search screen aggregates data from multiple domain object doesn't mean that the other processes and screen don't use that but from the application type at hand I would bet that most of the screens only deal with CRUD which brings me to another point:
  6. Another consideration Keith fails to mention is the type of application at hand. For the example given. It is probably a viable option to develop the whole thing as an Access application with embedded SQL in the controls. no OO and and no nothing.
  7. In any event. It seems to me Keith doesn't provide enough requirements to justify either of the solutions
In summary, yes it is completely wasteful to draw an off-hand solution that doesn't support any concrete requirements but that's an absolute truth whether you are using OO or no.

Edit 5/5: After looking at Evan Hoff's post on this. I understand that the point is  better delivered if you can also see the object model in question. So here it is:


Figure 1: Poor OO model - don't use

 
Tags: Design | OO

« Refactoring the GoF patterns (Singleton... | Home | SOA Patterns can save you time, money »
Monday, May 05, 2008 12:45:41 PM (GMT Standard Time, UTC+00:00)
Arnon,

Hello! You know, I'm really not sure why you are getting caught up on a really bad example that I state is absolutely bad and to not use it. I don't know if you understood the real point of what I was trying to go for when I created that bad object model and the post. I feel you may have missed the point entirely and got caught up on the wrong thing.

Here is a response to your points (in order):

1. You are right, that wasn't the point of the post.
2. It wasn't built with an expert involved which I referred to as: "After doing this little exercise I have to admit I felt very dirty. Seriously. Why? Because none of these objects fit into the what the Veterinary Clinic really needs.....". Reading between the lines that reads there wasn't a domain expert involved.
3. You missed the point, don't get caught up on a badly designed, already stated bad design up front.
4. There is probably some good discussion we could have on this one but I argue the three objects I outlined are in fact business objects. There is business logic in those objects (as I stated).
5,6,7: You have to understand that this article was written with using CSLA.Net in mind. CSLA is a business object framework. There isn't anything called 'domain models' when using CSLA. Everything is a business object. Hope that helps.

Thanks, take care.
-Keith
Keith Elder
Monday, May 05, 2008 2:10:23 PM (GMT Standard Time, UTC+00:00)
Hi Keith bad
I know you posted the design as an example of "bad design" however, the problem is that (IMHO) it is ridiculously bad design - i.e. something that anyone with any real OO experience would never come up with.
The result of that (as I see it) is that your post doesn't prove anything

If you say something is OOP and then say that OOP fails when that something isn't really OOP then what's the point?

Arnon
Arnon Rotem-Gal-Oz
Monday, May 05, 2008 6:31:12 PM (GMT Standard Time, UTC+00:00)
I have read plenty of articles where developers try to shoot down OO. However, two things are nearly always in play. One, their view of OO and how it applies to the common business application is rather skewed. And two, the example they choose to use is always nothing more than a database babysitting application with no real business logic to be found.

Here is something as close to a truth as I think you will find in software development. No one writing common business applications (Domains designed by and with domain experts with business logic taking precedence over CRUD operations, etc) truly uses a full-on object-oriented design as one might when building a game or other user-interface-centric application. What is closer to reality is that developers start with a domain model and implement it with classes. After that there are hundreds of variations of exactly how and to what extent OO concepts and heuristics are followed.

Because of this, I think anti-OO developers tend to condemn OO design based on the one flavor of implementation they witnessed.
Joseph Reddy
Monday, June 02, 2008 10:55:00 PM (GMT Standard Time, UTC+00:00)
I think the problem arises on both sides when programmers try to use "Objects" as a paradigm rather than a way to cleverly store data+methods in memory. The object structure is searchable it just needs a single base class(or some procedural code).
owen
Comments are closed.