I don't know of any "official" definition of a Manager, but here's my
definition. It's not so much a definition as an explanation of how I end up
with classes that have "Manager" in their name. :)

I start with a class that has grown far too large and unwieldy. I take
methods which I've subconsciously grouped together in the class or named in
a similar fashion, and refactor them into another class which ends in the
word "Manager" (the name is completely arbitrary but it sounds good). Once I
have them broken out, I try to decide if they look like any pattern I've
read about or seen before. If so, I change the name and refactor
accordingly. Otherwise, I stop there.

For (a grossly simplified) example, I had a request object that was the
entry point for handling every browser request to the Web site. It was in
charge of determining the event and the view and invoking the appropriate
event handler and/or display. As you can imagine, this grew over time. I
eventually moved everything having to do with events to an EventManager and
everything having to do with views to a...well, you get the point.

I usually resort to a manager when a set of related tasks become so large
that they begin to over burden an object. I refactor such tasks into a class
which takes over the responsibility of handling those tasks. The purpose and
intent of the original class is much more obvious when I'm done, which
always a good thing.

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057

________________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 26, 2004 4:17 PM
To: CF-Talk
Subject: Re: RE: What is a Factory?

Like Barney mentioned, class names may be local conventions without
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]

Reply via email to