Re: Why so many public properties all up in my grizzle?
Re: Why so many public properties all up in my grizzle?
- Subject: Re: Why so many public properties all up in my grizzle?
- From: Ian Joyner <email@hidden>
- Date: Sat, 17 Mar 2012 12:38:44 +1100
This is an interesting discussion, but there is a lot of misunderstanding of the concept of information hiding if not in what has been said here, but generally in the industry. This term was introduced by David Parnas, and I think it is a bit unfortunate because if you read his papers on this he really means implementation hiding:
On the Criteria to be used in Decomposing Systems into Modules (1972):
http://www-sst.informatik.tu-cottbus.de/~db/doc/People/Broy/Software-Pioneers/Parnas_hist.pdf
The Secret History of Information Hiding (2002):
http://www-sst.informatik.tu-cottbus.de/~db/doc/People/Broy/Software-Pioneers/Parnas_new.pdf
There is something deeper to this than simply hiding variables. A lot of people using C++, Java, etc think it means hiding data behind get and set routines. However, in reality we are trying to expose data, we are just trying to do it in an implementation independent manner. Thus it is the interface (API) is the important part of the design.
A corollary of this is Bertrand Meyer's Principle of Uniform Access, which says values should be provided to a caller in a uniform way, no matter whether the data comes from storage (variable), is computed either in an expression or a function:
http://en.wikipedia.org/wiki/Uniform_access_principle
http://martinfowler.com/bliki/UniformAccessPrinciple.html
I think Martin Fowler's article clearly shows Parnas's ideas.
Objective-C implements this principle of uniform access with properties.
Ian
On 17 Mar 2012, at 08:56, Conrad Shultz wrote:
> On 3/16/12 2:00 PM, Brian Lambert wrote:
>> This means that my UILabel called labelMyLabel is publicly available.
>> Anyone who has access to an instance of MyViewController can do anything
>> they want to with my label, including replacing it.
>>
>> Also, anyone who has an instance of MyViewController can call my
>> buttonDoItTouchUpInside action.
>
> In addition to David's remarks, it should also be noted that there isn't
> really any concept of "private" properties or methods (in the enforced
> sense) in Objective-C due to the dynamic nature of the language and
> runtime. No matter where you *declare* your properties and/or methods,
> what you state above would always be possible.
>
> (As an aside, major features in Cocoa rely on fairly crazy runtime
> manipulation. For example, key-value observing:
> http://mikeash.com/pyblog/friday-qa-2009-01-23.html)
>
> Suppose you wanted to peek under a class' hood (for curiosity's sake, of
> course; private API usage is generally a bad idea and is explicitly
> forbidden in the App Stores and from discussion on the official mailing
> lists). To see a class' properties (both from itself and its protocols)
> you could try something along the lines of (warning: a thrown together
> quick hack, probably has bugs):
>
> unsigned int propertyCount;
> objc_property_t *allProperties = class_copyPropertyList([MyClassName
> class], &propertyCount);
> for (NSUInteger i = 0; i < propertyCount; i++) {
> const char *name = property_getName(allProperties[i]);
> NSLog(@"%s", name);
> }
>
> unsigned int protocolCount;
> Protocol **allProtocols = class_copyProtocolList([MyClassName
> class], &protocolCount);
> for (NSUInteger i = 0; i < protocolCount; i++) {
> const char *protocol = protocol_getName(allProtocols[i]);
> NSLog(@"PROTOCOL %s", protocol);
> unsigned int protoPropertyCount;
> objc_property_t *protoProperties =
> protocol_copyPropertyList(allProtocols[i], &protoPropertyCount);
> for (NSUInteger j = 0; j < protoPropertyCount; j++) {
> const char *propName = property_getName(protoProperties[j]);
> NSLog(@"\t%s", propName);
> }
> }
>
> This and other fun hackery is documented in the Runtime Programming
> Guide:
> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide
>
>
>
> --
> Conrad Shultz
>
> Synthetiq Solutions
> www.synthetiqsolutions.com
> _______________________________________________
>
> 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
_______________________________________________
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