I agree, Teddy -- it's EXTREMELY important to consider the purpose of
each and every entity, and there should be no overlap of responsibility
whatsoever.  One of the standards we have at HCPro is that methods can
only be written once. So, if you feel a new method needs to be built,
you first have to research it from the ground-up to ensure that someone
else didn't beat you to the punch.  
 
What I mean is, if you recognize the need for a "getCustomerData()"
method, you first start with the CRM system adapter to see if the hooks
are already in place, which they probably are at this point.  Then, you
check the service layer controller to see if the hook is supported,
which it most likely is.  Then, you check to see if a customer object
has already been defined in the BL, etc.  Approaching model enhancements
this way really helps to keep redundancy to a minimum.
 
Also, just to clarify on a statement I made earlier regarding 6000
object instances -- these instances are based on a library of
approximately 30 classes -- about twenty BL entities and ten BL
entities, including the controllers.  The majority of the instances are
BL entities, since the SL entities only require one instance per
component.
 
Matt
 
Matthew Drayer
Development Manager
HCPro, Inc.
Marblehead MA
[EMAIL PROTECTED]
 
________________________________

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy
Payne
Sent: Tuesday, February 06, 2007 12:22 PM
To: [email protected]
Subject: Re: [CFCDEV] How many objects is too many?


Sammy has a similar perspective that I share about the original
question.
 
A lot of objects eventually means a lot of instantiations.  Loading the
objects into shared scopes can alleviate this and it is common for CFers
to do so.
 
The one that I really try to hold true is domain modelling.  If you add
a method to a given component, does it really make sense to have that
method there?  Is it directly related to the domain of that component?
Will the method be reused by more than one componet to warrant some sort
of service/abstraction?  Can I reclassify more than one domain together
to alleviate duplicate code? 
 
I am not insulting intelligence here, but what I mean by domain is the
overall scope or purpose of a object/component.
 
I shoot for domains that are relevant, compact and resuseable.
 
In short, can you reduce what you have and create more company and
reuseable componets?
 
Sorry that I cannot offer a quantitative measure.
 
Teddy
 
On 2/6/07, Sammy Larbi <[EMAIL PROTECTED]> wrote: 

        Hi Jaime,

        Funny enough, I posted about this a little while back at

http://www.codeodor.com/index.cfm/2007/1/15/More-classes-in-other-langua
ges-than-in-CF/877.


        I discussed more from the point of view of having fewer classes,
and
        thought that I may be subconciously writing bad code for two
possible 
        reasons (well, I didn't re-read the post for this, but this is
what I
        think I said):

        1) I may be concerned in the back of my head about the overhead
        2) It may be just some bad habits in CF, as I tend to have many
more 
        objects in Java (for instance)

        -Sammy Larbi


        Jaime Metcher wrote:
        > Hi,
        >
        > When you're modelling your application, how much attention do
you pay
        > to minimizing the number of objects instantiated?  Obviously
CF has a 
        > higher object creation overhead than some other languages.
OTOH, the
        > gist of much OO practice (and many patterns) is to create lots
of fine
        > grained objects.   I often read that a typical noob error is
creating 
        > too few objects with too many responsibilities.
        >
        > So, how often do you find yourself thinking "well, in Java or
        > Smalltalk I'd do xyz, but in CF I'd better not because I'd end
up with 
        > too many objects"?  Which is another way of asking to what
extent we
        > need to modify existing OO practices to allow for CF's
limitations.
        >
        > A couple of points of reference:
        > 1. This post was prompted by a discussion with Mark Mandel on
the 
        > transferdev list.  I'd spotted an issue purely because of the
massive
        > slowdown that occurred when 700 objects were inadvertently
created.
        > That issue has been resolved, but it left me wondering, if I
can't 
        > instantiate 700 objects how many can I create?  10?  50?  This
has
        > huge implications for how we architect our apps.
        >
        > 2. I have a Dolphin Smalltalk image that, from a fresh
install,
        > reports instantiating 160,000 objects.  Obviously with an
object 
        > system this slick you don't worry much about throwing in a few
hundred
        > more.  Given that CF's comfort zone is probably a couple of
orders of
        > magnitude lower, maybe a lot of the standard advice on OO
design just 
        > doesn't apply to CF?
        >
        > Any thoughts appreciated.
        > Jaime Metcher
        >
        > 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/[email protected]



        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/[email protected]






-- 
Teddy R. Payne
G-Talk: [EMAIL PROTECTED]

Adobe Certified ColdFusion MX 7 Developer
Atlanta ColdFusion User Group (ACFUG)
Atlanta Flash & Flex User Group (AFFUG) 
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/[email protected]


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/[email protected]

Reply via email to