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
