directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ersin Er <ersin...@gmail.com>
Subject Re: Immutable objects, what's best ?
Date Sun, 14 Mar 2010 13:56:04 GMT
You might consider builder pattern with a DSL like syntax:

Entry entry = new EntryBuilder().add("objectClass", "top").build();

where Entry is immutable.

On Sun, Mar 14, 2010 at 15:27, Emmanuel Lecharny <elecharny@gmail.com>wrote:

> 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.
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.nextury.com
>
>
>


-- 
Ersin ER
http://www.ersiner.net

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message