Hi! On Mon, Jul 6, 2009 at 07:01, Bernd Fondermann<bernd.fonderm...@googlemail.com> wrote: > On Sun, Jul 5, 2009 at 16:38, Michael Jakl (JIRA)<j...@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. 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. 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. I don't think we should be defensive programmers, if we give out objects we give them out to be manipulated. If we don't want them to be manipulated, don't expose them. 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 ;) > 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? Michael
