mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Immutable objects [WAS: Re: [jira] Closed: (VYSPER-92) Stanzas don't get enriched...]
Date Mon, 06 Jul 2009 09:06:46 GMT
Hi guys,

here, I would go in Bernd's way. Immutable objects have another 
additional advantage over standard objects : they are thread safe, in 
any case.

I would suggest to read Joshua Bloch's Effective Java, Itrem 13, for all 
the pros and cons of Immutable objects.

Bernd Fondermann wrote:
> Michael Jakl wrote:
>   
>> Hi!
>>
>> On Mon, Jul 6, 2009 at 07:01, Bernd
>> Fondermann<bernd.fondermann@googlemail.com> wrote:
>>     
>>> On Sun, Jul 5, 2009 at 16:38, Michael Jakl (JIRA)<jira@apache.org> wrote:
>>>       
>>>> Actually I don't think immutable object make much sense in an imperative
language, even though I know the advantages of immutable objects due to my experience with
functional programming.
>>>>         
>>> Wow, don't let your prof read this ;-)
>>>
>>> Java is an object-oriented languages. A major feature of OO is data
>>> encapsulation, immutable objects are a certain strict kind of data
>>> encapsulation.
>>>       
>> Encapsulation and immutable objects don't have much common ground, IMHO.
>> Encapsulation is *hiding* the internals of an object, returning immutable
>> objects is not.
>>     
>
> Of course they have (IMHO). Object = behavior + data. Immutable object =
> don't change my data! how these data is represented internally is up to
> the (immutable) object. If we decide to check for duplicates in the
> constructor, that's internal behavoir.
>
>   
>> This is exactly the reason why we can't easily change the list of Attribute
>> objects to a set of Attribute objects in XMLElement, even when it is immutable:
>> we told the world that we use a List<Attribute> to store them.
>>     
>
> That's more a contract problem. Even if we there were accessors for
> attributes (mutability), the internal representation would not be more
> easy to change from List -> Set.
>
>   
>> There are better ways to keep the implementation hidden whilst still providing
>> a similar functionality to the outside. Concerning lists, Visitors are one way,
>> Iterators another.
>>     
>
> Yeah, I think an iterator would have been a much better choice.
>
>   
>> I don't think we should be defensive programmers, if we give out objects we
>> give them out to be manipulated. 
>>     
>
> Not in this case.
>
> Example: A handler processes a message which he distributes (broadcasts)
> to a list of recipients.
>   The developer decides to iterate through the list of recepients and
> reuses the incoming stanza by setting the proper 'to' attributes and
> immediately hands the stanza over to delivery, expecting that the stanza
> is processed and gone when the delivery call returns. He continues to
> process with the next recepient. His unit tests succeed!
>   In production, recepients complain because they don't get messages or
> get a lot of duplicated messages at once.
>   What went wrong?
>
> I'm even more defensive than making Stanza immutable! For example, you
> cannot call StanzaBuilder.getFinalStanza() more than once without
> getting an exception.
>
>   
>> If we don't want them to be manipulated,
>> don't expose them.
>>     
>
> How can we not expose Stanza objects to Handlers?
>
>   
>> In the end, there is no "good" or "bad", just "Way A" and "Way B", I guess ;).
>> Probably the purpose of an object plays a big role here (value objects, logic
>> etc).
>>
>>     
>>> Immuntable objects are helpful when sharing information with code you
>>> don't trust or cannot control and where giving away a copy might be
>>> too expensive.
>>>       
>> Not every sin can be justified by performance considerations ;)
>>     
>
> +1. But in this codebase, I always tried to be as stateless as possible
> and generate the least amount of duplicated objects as possible. These
> general patterns help to increase the probability of better scaling.
>
>   
>>> Especially in parallel processing, immutable objects are
>>> indespensible, see Erlang.
>>>       
>> Agreed.
>>
>> Sorry to bring this up again, but I like discussions like this. Are there other
>> views on it?
>>     
>
> I changed the subj to make it more visible to others.
>
>   Bernd
>
>   


-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message