Re: private methods and variables
Re: private methods and variables
- Subject: Re: private methods and variables
- From: "Michael Ash" <email@hidden>
- Date: Wed, 30 Jul 2008 06:59:42 -0400
On Wed, Jul 30, 2008 at 6:26 AM, Torsten Curdt <email@hidden> wrote:
>>> Any pointers on how this is done?
>>
>> The true question is why you need this ?
>> I don't see any valid reason to require this kind of constraint.
>
> Well, those ivars while private still expose internal classes to the
> interface. I would like to avoid that for encapsulation purposes.
>
> Does that make sense? Or am I going here a little too far?
You're going a little too far. While you're showing it to outsiders,
you're not really *exposing* it, because there's nothing they can
legally do with the knowledge.
Encapsulation just means that outsiders don't rely on internal
implementation details of your class, so that you can change that
implementation without breaking clients. A private or protected
(protected is the default) instance variable, while visible to such
clients, still can't be used by them, so you can change it without
breaking them.
The fact that you have to put it in the header at all is just a quirk
of how the language is implemented. Subclasses need to know the total
size of their superclasses, so all instance variables must go in the
header. But it's still encapsulated, so don't worry about it.
(A big exception: if you are writing code which must remain *binary*
compatible with other code that may subclass your classes, an
exceedingly rare but possible scenario, then you must ensure that the
size of your superclass never grows from one version to the next, even
using private ivars.)
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden