RE: [CFCDev] Factory Pattern

[Scratch]

Sorry for the triple-post... u guys gave a lot of material!

Barney, in your example you have a UserFactory class - was that just an
example or do you normally build such granular Factories? How many factories
do your apps usually have?

Cheers,
Baz


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Barney Boisvert
Sent: Wednesday, November 02, 2005 12:58 AM
To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Factory Pattern

Factories are a two pronged deal.  A "normal" factory creates object
instances, where there are multiple instance of a given class.  For
example, and entity in your application (user, product, order, etc.). 
Service factories create service objects, of which there should be
only one of each class in your application.

In both cases, the factory is entirely responsible for creating the
instances and calling the init method.  Anything needing to be passed
to init must be available to the factory, and should NOT be dynamic. 
I.e. every object is created in exactly the same way.  Once you have
the instance, then you can supply custom state, if appropriate.

Here's a simple 'normal' factory (written in java-ish style, becuase
it's WAY less verbose):

class UserFactory {
  public User getNewUser() {
    return createObject("user").init(factory = this);
  }
}

Notice that while params are being passed to the init method, every
single user object the factory creates will get exactly the same
params.

Now here's an example of a service factory (again, java-ish style),
that illustrates configuation, object dependancy (though with no
resolution for circular dependancies), and generic create as you
included:

public ServiceFactory {
  public void init(datasource) {
    variables.dsn = datasource;
  }

  public AbstractService getService(name) {
    switch (name) {
      case "security":
        return getSecurityService();
      default: // any other types - all take a single param: dsn
        return createObject(name & "service").init(variables.dsn);
    }
  }

  public SecurityService getSecurityService() {
    if (NOT structKeyExists(variables, "securityService")) {
      variables.securityService = createObject("securityservice").init(
        dsn = variables.dsn,
        notifier = getService("notification")
      );
    }
    return variables.securityService;
  }
}

cheers,
barneyb

On 11/1/05, Scratch <[EMAIL PROTECTED]> wrote:
>
> I was recommended to build a Factory object to create my CFCs in the
> following manner:

<snip />

> The load() method takes a CFC name and calls the appropriate Create()
> method. My app should only call load().
>
> First off is this a good way? Secondly, if I use this way I seem to lose
the
> ability to pass already instantiated objects to my init() methods -
ofcourse
> I can still create new dependent objects and pass them in, which is the
> point of the whole thing, but what about passing in already instantiated
> objects? How does that work with Factories?
>
> Anyone care to post a link to their Factory file ;-)
>
>

--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/

Got Gmail? I have 100 invites.


----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).

An archive of the CFCDev list is available at
www.mail-archive.com/cfcdev@cfczone.org





----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to 
cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the 
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting 
(www.cfxhosting.com).

An archive of the CFCDev list is available at 
www.mail-archive.com/cfcdev@cfczone.org