Hi nathan
> Well, I figured people might be getting sick of my constant
> posts to this list, but since nobody else is answering..... ;)
This is the best cf-list I subscribed ever...
You are an important part of getting us over the mountain to the not
easy usage of cfc in an oo-way - thus please continue to share your
experience and knowledge ;)
- daniel
> Here's one way to consider doing what you're talking about:
>
> You could use what the patterns people call "composition" to
> have your components use each other. It's a fancy word for
> basically just having components use other components
> functionality. So, you might do something like this:
>
> application.ActiveDirectoryService =
> createObject("component","ActiveDirectoryService").init();
>
> application.UserService =
> createObject("component","UserService").init(application.Activ
> eDirectoryServ
> ice);
>
> In that scenario you would be passing UserService an instance
> of the ActiveDirectoryService when you instantiate -- you
> then have two cached component instances, one of which
> (UserService) has an internal "instance" reference to the
> ActiveDirectoryService. The guts of the UserService can then
> use the ActiveDirectoryService in its instance data without
> worrying about where that instance actually lives (which in
> that case of that code would be in the Application scope).
>
> So, now UserService has a clean way to use ActiveDirectoryService.
>
> When you instantiate your AceLinkUser into the session you
> could then pass the UserService to your init() method of
> AceLinkUser. UserService could then expose whatever methods
> are needed in ActiveDirectoryService. Or, you could just
> pass both to the UserService. Since components pass by
> reference there should be very little overhead associated
> this doing it that way. You might also consider having the
> init() method of AceLinkUser just get whatever information is
> needed from the other services directly. That is, rather
> than having the AceLinkUser component actually call those
> methods, just call them when you instantiate. In other
> words, instead of this:
>
> session.AceLinkUser =
> createObject("component","AceLinkUser").init(username,applicat
> ion.UserServic
> e);
>
> You could just do:
>
> session.AceLinkUser =
> createObject("component","AceLinkUser").init(username,applicat
> ion.UserServic
> e.isFacutly(username));
>
> Which one you use will depend on the extent to which the
> AceLinkUser uses the methods of the UserService and
> ActiveDirectoryService during its life a lot or just during
> instantiation.
>
> I'm also not sure if it's necessarily bad if both the
> UserService and the AceLinkUser have an isFaculty method.
> The UserService's isFaculty method receives a username and
> does some kind of data retrieval to give you the answer. The
> AceLinkUser's isFaculty() method just returns a boolean value
> (presumably already stored in the instance data) without
> needing an argument. So, although the methods have the same
> name, they serve different and appropriate purposes in the
> respective components.
>
> Those with greater OO design experience may have a better
> critique, but I've had good success using composition --
> particularly when I build a single component that gives the
> developer an API to use, where that single component has a
> few other "services" that get passed at init() time. That
> way the developer needs to learn only a single component's
> API and I can worry about the ways they interact with each
> other. Thus, I achieve a clean separation of interface from
> implementation. If you're interested in a working example,
> I'm almost ready to do the first public alpha test of a
> blogging tool that makes extensive use of composition
> (impart.sourceforge.net). I'd be happy to share that code,
> rough as it may be in its current form.
>
> - Nathan
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Behalf Of Dawson, Michael
> > Sent: Tuesday, August 19, 2003 12:08 PM
> > To: [EMAIL PROTECTED]
> > Subject: [CFCDev] Suggestions for Handling Multi-Use Methods
> >
> >
> > I'm struggling with the best location to put some methods
> that will be
> > used for both loading a session-based instance as well as
> performing
> > simple actions.
> >
> > For example, I have three components:
> >
> > AceLinkUser
> > --The main component
> > --Is aware of the user; stores data in an instance variable --An
> > instance of this will be stored in the session scope
> --Calls methods
> > from ActiveDirectoryService to load data during Init()
> --Calls methods
> > from UserService to load data during Init()
> >
> > UserService
> > --Used to gather user-related information
> > --Is unaware of data; only returns data to the caller; no instance
> > variables --Calls methods from ActiveDirectoryService
> > --Contains methods that pull information from other data sources
> >
> > ActiveDirectoryService
> > --Communicates with Active Directory
> > --Is unaware of data; stores connection information in an instance
> > variable --Does not consume any other components
> > --Contains the main LDAP query method
> > --Contains other utility methods that use the LDAP query method
> >
> > As you can see, AceLink user calls the other two components.
> > UserService, in turn, may also call the ActiveDirectoryService
> > component.
> >
> > To instantiate my AceLinkUser object, I need to know if a user is a
> > faculty member. This information is stored in an Active Directory
> > domain group.
> >
> > Currently, AceLinkUser's Init() calls "IsFaculty(username)
> method from
> > the UserService component. I could have also placed this
> same method
> > in the ActiveDirectoryService component, but I felt it
> would be best
> > to "abstract" the call by creating a UserService component.
> >
> > Is it best to keep the methods "at the lowest level" in the
> component
> > organization? Where is the best location for IsFaculty()?
> >
> > Is it bad to have a single component call a common
> component directly
> > AS WELL AS call a compoent that, in turn, calls the common
> component?
> >
> > I'm not really concerned about performance at this time. I'm only
> > interested in how components would be best structured in
> this example.
> >
> > Thanks
> >
> > M!chael A. Dawson
> > Group Manager, Programming and Software Development
> > Office of Technology Services
> > University of Evansville
> > 1800 Lincoln Avenue
> > Evansville, IN 47722
> > 812-479-2581
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
> in the message of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported
> by Mindtool, Corporation (www.mindtool.com).
>
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
