Good points. I was more explaining the motiviation for TOs, not necessarily recommending a development plan for CF apps, let alone people new to OO.
And I'll be the first to admit that I'm not particularly good at OO design. I'd say I've got a pretty good grasp on the underlying principles, but just as you described, implementing such a design is a heck of a lot of work, often work that gets done and then redone with the next revision. And as a dirty little secret, I never use TOs, I always use structs. ; ) cheers, barneyb On Thu, 6 Jan 2005 15:07:31 -0800, Sean Corfield <[EMAIL PROTECTED]> wrote: > On Thu, 6 Jan 2005 12:39:03 -0800, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > The main goal here is "don't let your business object leave your > > business logic layer." > > Good principle. Perhaps a little draconian in recommendation tho'. > > That leads to a proliferation of objects that "newbies" will have a > hard time managing, in my opinion. > > I'd be a little less worried about exposing business objects to the > view - and trusting the view to only call getters. > > I think people new to this stuff need to have an eye on the end goal > but need a clear transitional path. Switching from procedural > spaghetti straight to the OO end goal is a massive shift. It's much > easier to move incrementally and understand that "you're not there > yet" and have an expectation that you will need to keep refactoring > code to work toward the end goal. > > > In general, I'd > > recommend using the TO, but you have to make that call based on your > > application. > > I agree in principle and I think if people are comfortable with the > role of the TO they should use it. If they're not comfortable with it, > let them work up to it, using what's comfortable today but always > keeping a reminder that they need to revisit how they pass code > around. > > I'll share some of my process: > > I identify a bunch of core objects up front based on requirements and > analysis. Some initial design lets me build out those objects and get > things up and running. Then I go back and revisit each object, > ensuring it is cohesive and breaking things apart that aren't. Then I > go back and revisit each relationship, ensuring it is loosely coupled > and rearranging things that are tightly coupled. Then I go back and > refactor some more, focusing on reuse and commonality, building base > classes and / or composite utilities. Then I go back and refactor some > more to clean up code and to standardize interfaces. > > I may make releases along the way or I may not. But the refactoring > continues as maintenance continues, improving the structure of the > code with the implementation of every new feature or change. > > In other words, although I spend quite a bit of time up front on a > basic object model, I don't aim for perfect-first-time. > -- > Sean A Corfield -- http://www.corfield.org/ > Team Fusebox -- http://www.fusebox.org/ > Breeze Me! -- http://www.corfield.org/breezeme > Got Gmail? -- I have 5 invites to give away! > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 9 invites. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
