indeed. simply don't expose unwanted operations to the user. there's many ways to do that and wrapping it is just one of it.
On 13 May 2014 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 > > > > > -- Best regards, Igor Stasenko.
