recognized standard practices.
With that said, the "Gang of Four" defines a Factory Method's intent as
"Define an interface for creating an object, but let subclasses decide which
class to instantiate. Factory Method lets a class defer instantiation to
subclasses." (Design Patterns, p. 107) The UML diagram on the page Kwang
referenced is the one from Design Patterns.
As for a Manager--beats me! I've not seen any standardized definition of a
pattern or practice called Manager. As Dave so rightly put it, "a Manager
manages". ;)
- Jeff
On 26 Feb 2004 at 13:48, Kwang Suh wrote:
> Factories exist so that the developer doesn't need to worry about what
object they're creating (doing Foo foo = new Foo() is considered very bad
practice by some members of the OO community). This way, one can
change the factory to produce different objects within an object hierarchy.
>
> Take a look here: http://www.dofactory.com/Patterns/PatternFactory.aspx
>
> Personally, this is one of the more useful design patterns out there, but I've seen it misused (I once saw a system that used a factory object to create... factory objects).
>
> ----- Original Message -----
> From: "S. Isaac Dealey" <[EMAIL PROTECTED]>
> Date: Thursday, February 26, 2004 1:30 pm
> Subject: RE: What is a Factory?
>
> > Heh... that sounds to me like the functionality described for
> > "Manager" objects. Or at least without more information about a
> > specific scenario, the way I think I'd be liable to design that sort
> > of thing would place this functionality in a Manager rather than a
> > Factory.
> >
> > Thanks Mosh
> >
> > > Isaac:
> >
> > > A lot of times, a Factory is used to not only create but
> > > also to manage the
> > > creation of objects. For example, in a situation where
> > > you want to support
> > > database connection pooling, you would use a Factory to
> > > manage the creation
> > > an/or reuse of connections.
> >
> > > --
> > > Mosh Teitelbaum
> > > evoch, LLC
> > > Tel: (301) 942-5378
> > > Fax: (301) 933-3651
> > > Email: [EMAIL PROTECTED]
> > > WWW: http://www.evoch.com/
> >
> > > -----Original Message-----
> > > From: S. Isaac Dealey [EMAIL PROTECTED]
> > > Sent: Thursday, February 26, 2004 3:00 PM
> > > To: CF-Talk
> > > Subject: Re: What is a Factory?
> >
> >
> > > Boy that seems like a useless abstraction... The factory
> > > that is ...
> > > the Manager I understand, but it seems like if you wanted
> > > a new
> > > something to put into a manager, you'd just use "newThing
> > > = new
> > > Something(blah,blah)" instead of having a separate
> > > "factory" object to
> > > create them. Is there some other reason for it that I'm
> > > not aware of?
> >
> > >> On Thu, 2004-02-26 at 11:17, Troy Simpson wrote:
> > >>> All,
> > >>>
> > >>> I noticed that some application user the terms Factory
> > >>> and Manager in
> > >>> the Class/Object Names. Like AppFactory, AppManager,
> > >>> and
> > >>> EventManager
> > >>> in Mach-II
> > >>>
> > >>> 1. What is the general definition of a Factory?
> > >>> 2. What is the general definition of a Manager?
> >
> > >> In a very basic way (from a java stand point) a factory
> > >> produces and a manager manages
> >
> > >> so you'd tend to see stuff like
> >
> > >> Thing thing = Factory.createInstance() not
> > >> Manager.createInstance()
> >
> > >> Manager.add(thing)
> > >> not Factory.add(thing)
> >
> > >> Pretty much just what you think it does :)
> >
> > >> --
> > >> Rob <[EMAIL PROTECTED]>
> >
> > >>
> >
> >
> >
> > >
> >
> >
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
