mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Immutable objects [WAS: Re: [jira] Closed: (VYSPER-92) Stanzas don't get enriched...]
Date Mon, 06 Jul 2009 08:10:33 GMT
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
>> 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.


View raw message