managers as singletons and their implementations

[Allen Gilliland <Al...@Sun.COM>]

i've been wondering, is there a reason why all of our manager objects
are restricted to singletons?  the way the RollerImpl and
HibernateRollerImpl classes keep a reference to only a single
instantiation of each manager class seems strange to me.  most, if not
all, of those classes do not maintain any state and should be safe for
multiple instantiations, so is there a reason why we use singletons
instead?

my main worry is that our current manager classes all seem to have
public constructors, so if they really *should* be singletons then we
aren't really enforcing that.  anyone who wants to can simply construct
a new HibernateWeblogManagerImpl() rather than using the Roller
interface.  i think that if a class needs to be a singleton then it
should have a private constructor and a public getInstance() method to
ensure that the class cannot be instantiated more than one time.

this isn't causing any problems, but i noticed it as i was working on
the new ReferrerQueue which is required to be a singleton and i just
thought i'd bring it up as a question of coding practices.

-- Allen

Re: managers as singletons and their implementations

[David M Johnson <Da...@Sun.COM>]

On Jan 4, 2006, at 6:31 PM, Allen Gilliland wrote:

> On Wed, 2006-01-04 at 15:22, David M Johnson wrote:
>> There's no requirement that they be singletons, but there is some
>> cost to instantiating a RollerImpl in terms of object creation and
>> reading the Hibernate mapping files is costly, so we don't want to do
>> that more than once if we can help it.
>
> right.  the Roller object should probably be a singleton, but I was
> talking more about calls to roller.getXXXManager().  I think those
> methods could actually construct a new XXXManagerImpl instance to
> return, rather than maintaining a reference to a single instance.

They could, but why create objects when you don't have to?

- Dave

Re: managers as singletons and their implementations

[Matt Raible <mr...@gmail.com>]

On 1/4/06, Allen Gilliland <Al...@sun.com> wrote:
> On Wed, 2006-01-04 at 15:22, David M Johnson wrote:
> > There's no requirement that they be singletons, but there is some
> > cost to instantiating a RollerImpl in terms of object creation and
> > reading the Hibernate mapping files is costly, so we don't want to do
> > that more than once if we can help it.
>
> right.  the Roller object should probably be a singleton, but I was
> talking more about calls to roller.getXXXManager().  I think those
> methods could actually construct a new XXXManagerImpl instance to
> return, rather than maintaining a reference to a single instance.

I don't see any harm in making Managers and DAOs (don't think we have
any) as singletons.  As long as you're not maintaining state in
class-level variables, it shouldn't be a problem, should it?  This is
the pattern that Spring advocates (every bean is a singleton by
default) and it seems to work pretty well.

Matt

>
> -- Allen
>
> >
> > - Dave
> >
> >
> > On Jan 4, 2006, at 5:12 PM, Allen Gilliland wrote:
> >
> > > i've been wondering, is there a reason why all of our manager objects
> > > are restricted to singletons?  the way the RollerImpl and
> > > HibernateRollerImpl classes keep a reference to only a single
> > > instantiation of each manager class seems strange to me.  most, if not
> > > all, of those classes do not maintain any state and should be safe for
> > > multiple instantiations, so is there a reason why we use singletons
> > > instead?
> > >
> > > my main worry is that our current manager classes all seem to have
> > > public constructors, so if they really *should* be singletons then we
> > > aren't really enforcing that.  anyone who wants to can simply
> > > construct
> > > a new HibernateWeblogManagerImpl() rather than using the Roller
> > > interface.  i think that if a class needs to be a singleton then it
> > > should have a private constructor and a public getInstance() method to
> > > ensure that the class cannot be instantiated more than one time.
> > >
> > > this isn't causing any problems, but i noticed it as i was working on
> > > the new ReferrerQueue which is required to be a singleton and i just
> > > thought i'd bring it up as a question of coding practices.
> > >
> > > -- Allen
> > >
> >
>
>

Re: managers as singletons and their implementations

[Allen Gilliland <Al...@Sun.COM>]

On Wed, 2006-01-04 at 15:22, David M Johnson wrote:
> There's no requirement that they be singletons, but there is some  
> cost to instantiating a RollerImpl in terms of object creation and  
> reading the Hibernate mapping files is costly, so we don't want to do  
> that more than once if we can help it.

right.  the Roller object should probably be a singleton, but I was
talking more about calls to roller.getXXXManager().  I think those
methods could actually construct a new XXXManagerImpl instance to
return, rather than maintaining a reference to a single instance.

-- Allen

> 
> - Dave
> 
> 
> On Jan 4, 2006, at 5:12 PM, Allen Gilliland wrote:
> 
> > i've been wondering, is there a reason why all of our manager objects
> > are restricted to singletons?  the way the RollerImpl and
> > HibernateRollerImpl classes keep a reference to only a single
> > instantiation of each manager class seems strange to me.  most, if not
> > all, of those classes do not maintain any state and should be safe for
> > multiple instantiations, so is there a reason why we use singletons
> > instead?
> >
> > my main worry is that our current manager classes all seem to have
> > public constructors, so if they really *should* be singletons then we
> > aren't really enforcing that.  anyone who wants to can simply  
> > construct
> > a new HibernateWeblogManagerImpl() rather than using the Roller
> > interface.  i think that if a class needs to be a singleton then it
> > should have a private constructor and a public getInstance() method to
> > ensure that the class cannot be instantiated more than one time.
> >
> > this isn't causing any problems, but i noticed it as i was working on
> > the new ReferrerQueue which is required to be a singleton and i just
> > thought i'd bring it up as a question of coding practices.
> >
> > -- Allen
> >
> 

Re: managers as singletons and their implementations

[David M Johnson <Da...@Sun.COM>]

There's no requirement that they be singletons, but there is some  
cost to instantiating a RollerImpl in terms of object creation and  
reading the Hibernate mapping files is costly, so we don't want to do  
that more than once if we can help it.

- Dave


On Jan 4, 2006, at 5:12 PM, Allen Gilliland wrote:

> i've been wondering, is there a reason why all of our manager objects
> are restricted to singletons?  the way the RollerImpl and
> HibernateRollerImpl classes keep a reference to only a single
> instantiation of each manager class seems strange to me.  most, if not
> all, of those classes do not maintain any state and should be safe for
> multiple instantiations, so is there a reason why we use singletons
> instead?
>
> my main worry is that our current manager classes all seem to have
> public constructors, so if they really *should* be singletons then we
> aren't really enforcing that.  anyone who wants to can simply  
> construct
> a new HibernateWeblogManagerImpl() rather than using the Roller
> interface.  i think that if a class needs to be a singleton then it
> should have a private constructor and a public getInstance() method to
> ensure that the class cannot be instantiated more than one time.
>
> this isn't causing any problems, but i noticed it as i was working on
> the new ReferrerQueue which is required to be a singleton and i just
> thought i'd bring it up as a question of coding practices.
>
> -- Allen
>