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: Sebastian Celis <email@hidden>
- Date: Mon, 19 Mar 2012 15:35:25 -0500
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 (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