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 <dastels@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 <emaringolo@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.tymchuk@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.