"Bob Sidebotham" <bob / windsong.bc.ca> schrieb im Newsbeitrag 
news:Dco7d.162456$%S.13340 / pd7tw2no...

> Thanks for the observation. You may be right that keeping levels separate 
> would be a good idea. Still, if I hand you an object, and tell you that I 
> want you to do something with a set of items that are somehow associated 
> with the object (which in this example, I've called "fields"), and if I 
> tell you that you can get a list of those fields by calling some 
> particular function, why should I ALSO have to tell you HOW to call the 
> function (i.e. foo.fields vs. foo.class.fields). Doesn't this break 
> encapsulation by forcing the caller to know too much about the internals 
> of the receiver?

Yeah, I guess you are right.  In that case, defining those fields at class 
level is just an optimization of the implementation.  In this case I'd 
definitely freeze the array (or return a copy of it, if you need to be able 
to change the set of fields of a class) to avoid unwanted effects.  Because 
the info is stored in the class instance unwanted modification will do more 
harm than if it was stored on instance level: *all* instances of the class 
will then have their "fields" property changed.

> In this case, I think it's a minor point, anyway: the two classes are very 
> closely related and not intended to work independently.
>
> I think part of the issue is that the right answer to a question like this 
> perhaps depends upon the application. So without knowing more about the 
> application, and the context within which all this happens, I'm not sure 
> you can say that one pattern is necessarily better than the other.

That's definitely true!

Kind regards

    robert