directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Immutable objects, what's best ?
Date Sun, 14 Mar 2010 13:00:51 GMT
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 ?

Emmanuel L├ęcharny

View raw message