> From: Anton Tagunov [mailto:[EMAIL PROTECTED] > > Hello, guys! > > Farr> b) Should MutableConfiguration extend > Farr> Configuration? > > LSU> public class DefaultImmutableConfiguration > LSU> implements Configuration > LSU> { > LSU> DefaultImmutableConfiguration (Configuration config) > LSU> { > LSU> ... > LSU> } > LSU> } > > LSU> The constructor will do a deep copy of the supplied > Configuration, > LSU> thus ensuring that the instance is immutable. > > The class looks usefull indeed. > One reservation nevertheless: > > * the main use case is to allow different storage > structures behind MutableConfiguration > > right?
No. The purpose is to allow an application to code against an interface (MutableConfiguration) instead of against a concrete class (DefaultConfiguration). > * this is done to choose between > > - faster > - low-memory-footprint > > implementations depending on evironment > (desktop/server/Java2ME) > and size of configuration provisioned > > right? No. > *IF* both answers are 'yes', then I'd prefer not to > deep-copy the configuration data unless it's unavoidable The deep-copy is done when you absolutely, positively have to ensure that a configuration is immutable. > If we want to conserve memory then I'd go about it like > once the container has passed configuration to client > that will hold on if for ever and ever, the container just > stops modifying it. That's fine as well. The container should do that. But: The DefaultImmutableConfiguration is for when you receive a Configuration, and *don't* have a guarantee that you'll be able to hold on to it for as long as you'd like to. Copying it to a DefaultImmutableConfiguration means that you have one immutable snapshot of it. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
