The one problem with creating an instance is that the flyweight needs to be able to get back to his "home" to reconstitute the object. If it's some instance floating around, that's harder.
On Tue, Jul 20, 2010 at 2:43 PM, James Carman <ja...@carmanconsulting.com> wrote: > On Tue, Jul 20, 2010 at 2:36 PM, Matt Benson <gudnabr...@gmail.com> wrote: >> I know what you mean; it's potentially not that much code. Maybe start in >> the sandbox and, once everything's working satisfactorily, decide what to do >> with it? As for memory, what if you actually put the map of flyweight >> id:instance onto a Flyweights class and managed *its* id mappings >> statically/weakly? Then a given Flyweight would just become expired >> whenever its owning Flyweights instance () was no longer accessible, and its >> getObject could reflect that somehow. Typically it would be a sign of a >> programming error if a Flyweight associated with a given container were used >> after its container had been reclaimed, so a simple exception might be >> enough. Just ruminating... >> > > Interesting thought. I'll have to churn on that one a while. > Basically what I'm trying to do is come up with a nice re-usable way > to solve the writeReplace()/readResolve() problem so that most folks > can understand it. I can see having a superclass that automatically > registers a Flyweight for itself and spits that out in its > writeReplace() method. Then, when anyone wanted that functionality, > they could extend that superclass. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
