Last Week, Peter Bell wrote a post, asking the ColdFusion community "How Many Classes Per Business Object?" The debate that came out of it was very interesting, with a number of people chiming in on the plusses and minuses around multiple classes. Some were in favor of multiple classes, some thought one was enough, a few thought the "OO Purists" were creating too much complexity.
This debate carried over into our office, as it frequently does. Andy Matthews is a co-worker of mine, a very gifted developer with a keen eye towards aesthetics, coming originally from a designer's background. That being said, Andy is learning Object Oriented theory right now, having worked primarily in a procedural world in his past, and beleives that frameworks and design patterns are generally overkill. He's not a fan of my use of the Active Record pattern, Service Factories, or Remote Proxies, believing that there's way too much up-front work involved in what should be relatively simple.
Some time back (about a year and a half) I began a Data Modeling repository within our system. It was a collection of objects, primarily based around the Active Record pattern, to be used while interacting with various tables within our databases. In the beginning I wrote my own objects, to learn how the process worked and refine and define the concepts within my own development work flow. After I had a better understanding of everything I began to use the Illudium PU-36 Code Generator. I was able to modify the XSLT files to create classes that suited our needs (commenting, var scoping, etc.) I don't use this library for everything, but it does cover most of my needs very efficiently and effectively.
What I like is the separation of the classes. A bean is nothing more than a data representation of an object, with no logic at all, outside of simple validation. A Data Access Object is nothing more than single record Create - Read - Update - Delete. A Gateway is multi-record access, and a Service Factory is for dealing with collections of related objects. Seem like a lot? Well, it can be. But imagine all of it within a single class. The beauty of working within this sort of paradigm is it's separation. When you need a change to logic you go to your controller, and maybe your Service Factory. One record? Check out your bean and your DAO. If you have a change to your db structure it is quite possible to regenerate your base objects and make minor adjustments at the view layer, for added or deleted fields, without having to make sweeping changes all the way through. Why? You've created a consistent model for data access and manipulation.
What I've found, in working on different applications for different clients, is that there have been many places where data access and business objects are replicated in multiple locations of a system. An update to the code would occur in one spot, and was forgotten in another, causing inconsistent results. Providing a common library of access and logic provides consistency and single point adjustment and maintenance. A separation of business objects, according to the task at hand (property access, record access, dataset access, etc.) makes for smaller, trimmer classes that become instantiated into memory only when needed, destroyed when not (if you're var scoping properly) and using much less resources than a large, do-it-all type of object. That being said, the objects I've referred to in this post are definitely not the end-all-be-all way of doing things. In fact, although great for simple objects, simple table access, and simple forms, they can be quite convoluted when dealing with very complex objects that model real world objects, rather than a database table (enter the Service Factory). Design patterns are outstanding, and can definitely simplify and speed your development, once you have a grasp of their concepts, but no one pattern suits all needs.
So, Andy and I will continue to debate the use of design patterns and frameworks. Peter has decided on One Service Class Per Business Object, and I'm quite content to continue to explore new design patterns and frameworks to assist me in my development. It's how I do it, I find it to work well for me and the applications that I write, but I adjust as I learn more. That's part of the beauty of ColdFusion, you aren't nailed down to one way of doing things. With it's dynamic typing and OO-like constructs alike, you can have the best of both worlds and code in whatevery style suits your purposes best, and the needs of your client.