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.

Dan Wilson just jumped back into the OO discussion with an interesting take on why OO . . .

If anyone is still having a hard time with OO in CF, check out the new series of postings by Nando on OO in CF. Looks like it could be a great series.

And for other OO advice remember to check out Brians big resource list for OO and frameworks and Doug Boudes lighthearted by informative intro to OO terminology.

A lot of people know what CFC's are but aren't really sure how to start to go about architecting their ColdFusion apps. There are a bunch of resources out there, but I though I'd add one more with a CFDJ article on Architecting your ColdFusion Objects that has just been published. It tries to provide a high level overview of where, why and how to use OO design patterns to create more maintainable CF apps. Any input appreciated!

Wow, three articles on my author page in three months - cool :->

I have seen posts and comments over the years from a number of developers who feel OO is getting a little too much press. They point out (quite reasonably) that many applications don’t need to be Object Oriented, but some also suggest that Object Zealots (I'm a card carrying member :->) are proposing we OO everything from single page forms on up.

In my personal experience, the biggest proponents of Object Orientation and Design Patterns tend to be strongly opposed to the unnecessary use of patterns or OO principles. I for one still have some smaller apps that are proudly procedural and many that have cfqueries in their views. Some of the projects are old, others just didn’t need the additional complexity.

So, I am calling for everyone who likes and dislikes OO alike to comment below, listing these blog postings where Object Oriented proponents suggest that we brazenly and maliciously overuse Design Patterns and Object Orientation on our simplest forms and screens (other than perhaps as a learning tool which I see as a valid excuse) as then we can present a united front against this diabolical evil and return to the saner problems of how to learn OO and DP (if appropriate/relevant) and where best to utilize them.

I know some of my posts might seem a little esoteric for anyoe just getting started with Object Oriented programming in CF. As mentioned before, I will be posting at least one "OO 101" post every month to provide a resource for getting started.

In the meantime, anyone interested in getting going with OO or frameworks should check out the great list of resources Brian Rinaldi just posted. An excellent resource!

If you're not sure why you should consider OO programming at all, check out this brief summary - or this one.