On 3/14/10 9:46 AM, Stefan Seelmann wrote:
Emmanuel Lecharny schrieb:
Hi,
we have many objects that we want to be immutable. What's the best solution
to produce those immutable objets ?
- For DN, we would like to use valueOf(), and the DN() constructor, but no
setter
- For Entry, a constructor is not enough, as we may have to inject new
attributes. We may need to have two different classes, one immutable, one
mutable. The immutable class could be associated with a factory, or we can
use a constructor with the list of attributes as a parameter.
- For attributes, we have the same problem : we may have more than one
value.
DO any of you guys have a strong opinion ?
Entry and Attribute object created by the user of the API shouldn't be
immutable. As user of the API I want to create an Entry object and add
attribute and values to it. So the API must provide setters.
I came to the same conclusion, but with another idea : create two Entry
objects, one for the client, one for the server. It's close to what we
have on ADS, but the more I think about it, the more I find it complex
and bothersome.
Now, let's think about another option : what if we add a parameter in
the constructor to create Immutable Entries ? Something like :
Entry immutableEntry = new EntryImpl( DN, true ); // True => the entry
is immutable ?
So I think if Entry and Attribute are interfaces we just define the
getter methods.
Smart ! That could do the trick, sure ! But is it better than the
previous solution?
My idea was to forbid a setter to be called if the Immutable flag is
set, a solution I find a bit more strong than hiding the setter though
the interface, but it forces the user to add a flag to the constructor.
Again, what do you think is the best approach ?
The default implementations of those classes (e.g. ClientEntry and
ClientAttribute) additional have setters the user can use when
constructing the objects.
The Entry objects returned from the API (e.g. from a search) should be
immutable to protect them from being casted by the user, e.g. by
wrapping a created ClientEntry into an ImmutableEntry implementation.
Hmmm... Do you suggest that we should define 2 different classes ? (one
immutable, one mutable). Wouldn't it be better to have one single
implementation, with a limited interface, forcing the user to cast to be
able to use the setters ? Or should we have a ClientEntry class
extending a ServerEntry class ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
