Just let me know if any outstanding questions! Best Wishes, Peter
On 8/29/07 11:00 PM, "Justin Treher" <[EMAIL PROTECTED]> wrote: > Peter > I see you have a blog entry about it from March. I¹ll check that out. > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell > Sent: Wednesday, August 29, 2007 6:30 PM > To: cfcdev@cfczone.org > Subject: Re: [CFCDEV] Ok, now I have a question re: composition > > I cheat. I have a business object called ³value list² which allows the users > to manage all of their simple value lists and I gen the CRUD for the value > lists, so users can manage their state list, order status list, employee type > list, etc without us having to generate a bunch of code for each by treating > them all as separate business objects. > > Best Wishes, > Peter > > > On 8/29/07 6:12 PM, "Justin Treher" <[EMAIL PROTECTED]> wrote: > Gotcha Peter. I was looking at enumerated values in Java and that that might > be the way to go. However, what about giving users an interface to edit those > values? Should they, at that point, become an object with a GW and DAO? Or is > there a simpler way to provide an interface to edit those list values? > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell > Sent: Wednesday, August 29, 2007 5:57 PM > To: cfcdev@cfczone.org > Subject: Re: [CFCDEV] Ok, now I have a question re: composition > > Its a choice, but personally I have the concept of a ³Value List². Whenever I > have a list of values that have a title and possibly a name, but no other > properties, I treat them as a value list. It is similar to an enum, but allows > the title and name to be different (e.g. ³New York² vs. ³NY²). While it isn¹t > wrong per se to turn every list of values into a collection of objects, if you > just want a drop down list of US states, I¹m not convinced that needs to be a > collection of objects. Same with book types and wand materials. If on the > other hand different book types have a collection of properties and/or custom > behaviors, implementing them as objects might make perfect sense. > > Best Wishes, > Peter > > > On 8/29/07 5:34 PM, "Justin Treher" <[EMAIL PROTECTED]> wrote: > I guess I need to dive into an ORM now that I¹m experiencing the problem it > solves. > > Composition, delegation, and aggregation seem to be tough concepts for me to > understand with respect to when I should be using them vs. a structure that is > filled from the database. > > Example: > > Blog has a property categories > > We need a select list filled with possible categories for our new blog entry. > Is that select getting category information from a category object or is this > a struct filled from somewhere? > > I¹ve been handling this situation like this: > > Blog¹s categories property is an array of category objects. Category has its > own bean, GW, and DAO. While this seems ok because I need to edit categories > independently, category really doesn¹t have any behaviors. > > So do I pretty much handle all properties of this type like that? > > Address -> State is an object of State > Members ->MembershipTypes is an object of membershipType > Books -> BookType is an object of BookType > Wand -> Materials is an array of objects WandMaterial > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Kotek > Sent: Wednesday, August 29, 2007 4:50 PM > To: cfcdev@cfczone.org > Subject: Re: [CFCDEV] Tom Minderson and anti-OO > > Sounds like someone who doesn't get OO and has decided that he must be right > and the rest of the programming world is wrong. > > On 8/29/07, Justin Treher <[EMAIL PROTECTED]> wrote: > > I do see his point that trying to map objects to a relational database is > where OOP starts to feel really unnatural. In addition, with the business > objects we deal with, it seems unnatural for them to have behaviors, unlike a > car being able to "start()". > > > > Dealing with relational databases is what ORM was created for. Regarding > business objects, if you have objects with no behavior you basically might as > well just be using a structure. I would disagree that it is unnatural for the > business objects we deal with to have behavior. If objects shouldn't have > behavior, where does the actual application logic go? If you don't encapsulate > the behavior with the data (in an object) then it just results is spaghetti > code all over the place. > > shipment.determineShippingTime() > inventory.adjustInventory(order) > contentCache.clear() > > These seem perfectly natural to me. Basically, even if you don't completely > understand or even agree with the idea of OOP, the rest of the world does. > Failure to embrace, or at least understand, OOP in this day and age is going > to translate to a difficult programming career. > > > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
