On Mon, Mar 19, 2012 at 2:27 PM, Brian Lambert wrote: > Is there a way to declare ivars in the .M file AND have them accessible > from Objective-C Category files for the class?
I will tell you how we handle public, private, and protected ivars and properties. The route we decided to take was influenced by a number of overall design goals: 1) Embrace @properties. Properties are great. They make memory management easier, they work with ARC, and they force us to document our code and think about relationships between objects (weak vs strong, atomic vs nonatomic). Exposing _ivars in header files is gross. You never want people to access them directly, so don't make those declarations public at all. Exposing _ivars without properties in .m files is also gross, as it is not clear whether those relationships are supposed to be strong or weak. 2) Technically, nothing is truly private in Objective-C, so let's stop trying to completely prevent people from using private APIs. Let's just adopt a convention that is clear and lets people know that if they use private APIs they do so at their own risk. 3) Protected and private APIs (including ivars) should not autocomplete most of the time in Xcode, so they should not be in the public header file at all. We want the header file to be clear, concise, and very readable. Given those decisions, here is how we currently do things: * Public ivars are always declared as properties in the class header file. The _ivar should not be declared in the header file at all. Let the synthesizers declare them in the .m file. _ivars needlessly complicate the public header files for your classes, so keep them out. * Don't be afraid to mark many of your public properties as readonly. You can always override the property declaration as being readwrite in a class extension in the .m file. * Private ivars are declared as private @properties in the .m file. Again, let the synthesizers actually declare the _ivar. Don't declare the _ivars yourself, as it won't be immediately clear whether the references are supposed to be strong or weak. Use properties! * Protected methods and properties are tricky. We want subclasses to be able to access these directly, but we don't want API consumers to see them when autocompleting in Xcode or when looking at the public header file. So, we decided to do what Apple does with UIGestureRecognizerSubclass.h. We create a special header file that defines all of the protected properties and methods of a class using a category. Then, any subclass implementation files can import this file to easily access those protected APIs. Yes, nothing is stopping a bad developer from importing this header file and using protected APIs when they shouldn't, but they are hidden in a different file and appropriately documented so that developers don't accidentally use them. There are many ways to handle public, private, and protected APIs in Objective-C. We have found this to be a clean approach that works for us. - Sebastian _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
