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:27:43 GMT
On 3/14/10 2:19 PM, Stefan Seelmann wrote:
> Emmanuel Lecharny wrote:
>> 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 ?
> I don't like it if a setXXX() method is provided and if I call it some
> "YouIdiotAreNotAllowedToCallThisMethodException" is thrown.
> So IMO having the interface which provides read-only methods is best.
> And if using the EntryImpl you have all the setters and the setters work.
> Then you can obtain an immutable Entry from that EntryImpl, see below.
>>> 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 ?
> I wouldn't call it ClientEntry and ServerEntry, sorry that I used that
> name before ;-)
> In the public API I would define an default implementation (not sure
> about the name, we discussed some names before) which is mutable. This
> implementation is used by the user because I don't think he wants to use
> an immutable implementation.
> The immutable implementation just works like the java.util.Collections
> class, there are static methods like unmodifyableSet(Set set). So we can
> have some Utils class which wraps the default mutable class into an
> immutable. Or the default Entry implmentation could provide a method
> "toImmutableEntry()". The immutable implementation shouldn't be part of
> the public API.
> wdyt?

Sounds good. I will update the wiki with such a proposal.

Emmanuel L├ęcharny

View raw message