I enjoyed reading Ben's series on Hal Helms course on OO programming. I didn't attend the course, and I've never heard Hal to say anything except for very smart things that I've learnt greatly from, but I do want to make a bit of a counterpoint post. From a brief reading of Bens post (and I apologize in advance if I'm misrepresenting anything Ben or Hal said), it sounded to me like there was a focus on "what would the real world object do" as a way of determining the responsibilities for a given object. If you're coming from a procedural background, that might be a useful *exercise* to get you thinking about objects, but to me it simply isn't the primary concern when coming up with an OO design.

To me the purpose of an OO application design is not to accurately model or reflect the real world behavior or capabilities of an object. There is nothing wrong with playing with that as an approach and it may help with some designs, but I don't see it as an arbiter of a good design. A good OO design is one where behavior and data are appropriately encapsulated, where the reasoning behind design decisions is consistent and easy to understand, and where (most fundamentally) the application will be easy to maintain with good encapsulation of what is most likely to vary.

A good OO design for a given use case is highly dependent on the technical environment and the parts of the technical system that are most likely to change. To try to design ideal objects, to me is YAGNI. I'd rather suitably apportion functionality between class files based on heuristics like the single responsibility principle, maximizing cohesion and minimizing coupling and encapsulating that which is currently most likely to change. As such, I would argue that the "best" design for a given OO app is highly dependent on technical requirements and what's most likely to change in those technical requirements and to try to write an OO program that isn't technology aware is like trying to design a car that runs like a horse.

I am not saying that there is not value in the "ontological approach" of "what is my object". I *am* suggesting that while that may be useful, it is definitely not the final arbiter of good design. The final arbiter of good design is how elegantly and maintainably you've implemented the technical requirements. Object oriented programming is a tool to make your applications more maintainable, nothing more, nothing less.

Just my 2c.

In Jared’s recent great posting, he talked about how he had argued in the past that beans shouldn't have a this.validate() method. I just wanted to take a little more time to look at approaches to validating objects and architecting these kinds of solutions.

[More]

Jared has just posted a thoughtful and thought provoking article on anaemic domain models and architectural approaches in CF. Unfortunately, I would argue that he has missed the boat in some ways and taken it to an extreme in others :-> (read the post, you'll get the reference)

[More]