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: Matt Neuburg <email@hidden>
- Date: Mon, 19 Mar 2012 14:34:24 -0700
On Mar 19, 2012, at 12:45 PM, Brian Lambert wrote:
> ivars in the .H file of my Foo class, which no one other than me will ever use, should be relatively OK. After all, I'm not trying to prevent myself from knowing anything about my implementation of Foo. I'm just trying to ensure that my *intent* for my class is well-understood to other programmers who will work on Foo in the future.
In my experience, that's not a good way to think about what writing an OO program. (1) The main programmer who may work on Foo in the future may be me, but I think of him as one of those "other programmers". I can guarantee that I won't have the slightest idea what this program does or why my intent was, probably as soon as tomorrow, if I don't express it clearly in the program itself. (2) OOP is about expressing contracts. Now that ivars that are not intended as part of the public face of a class no longer have to be in the header file, it's best to take advantage of it if possible so that the program expresses the intended architecture.
Here's a case where declaring the ivars in the implementation file wouldn't have worked for me:
https://github.com/mattneub/Programming-iOS-Book-Examples/blob/master/ch37p920downloader/p754p772downloader/MyDownloaderPrivateProperties.h
Okay, it's properties not ivars, but the idea is the same. I want a subclass of MyDownloader to know about these properties. The way to do that is to declare them in a class extension and have the subclass (MyImageDownloader) import the file with that class extension.
Hope that helps -
m.
--
matt neuburg, phd = email@hidden, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.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