Ok, I also forgot to tell my own opinion. If you as something for it’s model (or some other thing), you get it. Now it’s up to you if you want to modify it or not. The idea behind encapsulation rules is that you don’t force someone to rely on your internal data. So to allow someone add thing to your list you implement #add: method that takes one item and adds it to internal collection. But this doesn’t mean that you lock that collection from being modified when you return it. If someone want’s to write bad code he will do it anyway. One thing that you shouldn’t do is to enforce bad practices.
But this question was really to gain knowledge from experienced computer scientists/engineers. Cheers Uko On 13 May 2014, at 15:47, David Astels <dast...@icloud.com> wrote: > Well, an issue of good OO design or not. Returning a mutable collection > breaks encapsulation. My initial question is whether the collection is simply > a detail of the implementation or part of the external interface you want to > expose. If the former, hide the collection and expose operations that > provide what’s truly needed. If the latter, then you might need immutable > collections. > > Java devs aren’t crazy… they just tend not to understand OO very well. > > Dave > > On May 13, 2014, at 8:28 AM, Esteban A. Maringolo <emaring...@gmail.com> > wrote: > >> I think it is more an issue of design. >> >> If your Invoice has a collection of "Items", you shouldn't manipulate >> the collection directly and instead use accessor/operator methods. >> >> I wouldn't restrict having the option of direct manipulation of the >> collection, but it is a nice thing to have covered by some LINT rules. >> :) >> >> >> Regards, >> >> >> Esteban A. Maringolo >> >> >> 2014-05-13 6:53 GMT-03:00 Yuriy Tymchuk <yuriy.tymc...@me.com>: >>> Hi, >>> >>> sorry if there was already this question, but I couldn’t find it anywhere. >>> >>> I’m looking in the OO-design concerns and it seams that Java guys are crazy >>> about returning the collection that is used for state of an objects. The >>> only acceptable option is returning it in the immutable wrapper. As far as >>> I know, pharo does not have immutable collections (except from intervals >>> and symbols). Are we missing something important, or there is a philosophy >>> behind the building blocks we have now, and the design we come up while >>> using them. >>> >>> Cheers. >>> Uko >> > >
