Composition instead of inheritance. Composition is favored over inheritance by the Sun people and others who research OOP best practices. You should not overload a person object to make it an engineer, or a husband. but rather pass in the job object, and the marital status objects. Inheritence the way you speak violates the liskov substitution principal, and should be avoided. Mixins are kludgy fragile code which is hard to test, and difficult to document.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sammy Larbi Sent: Thursday, February 01, 2007 7:13 AM To: cfcdev@cfczone.org Subject: Re: [CFCDEV] Closures, mixins, and udf includes 4. Multiple Inheritance - A person can be an engineer and a husband and any other number of things. How can you have this functionality unless you are putting a bunch of methods in the Person class that don't really belong. Jaime Metcher wrote: > I can think of three rationales for mixins: > > 1. > To make dynamically defined "helper" methods available to clients of the > original object. This can't be done by simple delegation - you have to know > about a method before you can delegate it, and the mixin might not be known > until runtime. > > 2. > Where the methods are known but not always wanted, like debugging hooks. > You might have a debugging factory method that mixes debugging methods into > all your objects, where the production factory method does not. > > 3. > Where you really could handle it with delegation but are too lazy to write > all the delegation methods. I think it's this last one you're expressing a > dislike for. In general I would agree with you. > > Oh, I just noticed you were looking for replies from smart experienced > folks. Oh, well, too late now...;) > > Jaime Metcher > > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barry >> Beattie >> Sent: Thursday, 1 February 2007 2:58 PM >> To: cfcdev@cfczone.org >> Subject: Re: [CFCDEV] Closures, mixins, and udf includes >> >> >> more like >> >> >> objA = CreateObject("component", >> "A").init(application.kernel.getHelper()); >> >> <cfcomponent name="A"> >> >> <cffunction name="init"> >> <cfargument name="helper" type="any" hint="helper >> routines in a CFC to decorate this CFC" /> >> <cfset variables.helper = arguments.helper /> >> <cfreturn this /> >> </cffunction> >> >> </cfcomponent> >> >> (actually for smaller jobs I've just been passing a reference to the >> kernel into the CFC and running the getHelper() within there, since >> most of the time the CFC actually decorates the kernel - think of it >> as a reference back to the parent) >> >> >>> What hassle? >>> >> two things I don't like about includes (within CFC's) are: >> managing the include files in conjunction with CFC. in a case of an >> include for each SQL statement where there's 50 of them that's 51 >> files to move around. >> >> documentation: comming across a helper method and asking "WTF is this >> and where did it come from?" instead of <cfreturn >> variables.helper.doSomething(result) /> and additionally, seeing what >> helper.doSomething() is in the CFC explorer. Perhaps I've been burnt >> by Fusebox 3 bad practices? >> >> I realise that everyone has their favourite mousetrap. I just prefer >> to have methods (even static ones) within CFC's. Infact the only time >> I bother now-a-days with cfinclude is for taglibs for the UI. >> >> different strokes, etc. >> >> cheers >> b >> >> > > > > > 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 **************************************************************************** This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. **************************************************************************** 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
