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 > > >
