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

Reply via email to