I have some very boring meetings to attend this morning, so I'm going to print this and take it along for some enjoyable reading.
I, personally, enjoy seeing your posts. Without "sucking up". I'd consider you one of the elders of this list. I have learned quite a lot about components from your posts. Also, I would really like to see the code you have so far. I'd like to compare it against what I have created. Thanks once again, Nathan! -----Original Message----- From: Nathan Dintenfass [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 10:52 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Suggestions for Handling Multi-Use Methods Well, I figured people might be getting sick of my constant posts to this list, but since nobody else is answering..... ;) 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.ActiveDirectory Serv 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,application.UserSe rvic e); You could just do: session.AceLinkUser = createObject("component","AceLinkUser").init(username,application.UserSe rvic 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).
