Jun 97 - Getting Started
Volume Number: 13
Issue Number: 6
Column Tag: Getting Started
Filling in Some of the Objective-C Pieces
by Dave Mark
Last month, we learned most of the syntax of the Objective-C language. Since then, I
have been scorching the e-mail, newsgroups, and phone lines trying to learn more.
Much thanks to Michael Rutman, David Klingler, Bob McBeth, and Eric Gundrum for
their time and energies in trying to get me on the straight and narrow. As always, the
good stuff is theirs, the mistakes, mine.
@private, @public, and @protected
For me, much of the Objective-C learning process involves learning the differences
between C++ and Objective-C. For example, C++ allows you to use the access
specifiers public:, private:, and protected: to define the scope of a classes' data
members and member functions. Objective-C offers a similar mechanism you can use
to specify the scope of a classes' instance variables (methods are always public): the
compiler directives @private, @public, and @protected.
Here's the official description of each of these compiler directives:
@private
the instance variable is accessible only within the class that declares it.
@protected
The instance variable is accessible within the class that declares it and within
classes that inherit it.
@public
The instance variable is accessible everywhere.
Instance variables default to @protected, which makes sense. After all, if you mark an
instance variable as @public, that would defeat the whole point of data encapsulation.
The point is, you want to force access to your instance variables to occur via one of
your classes' methods. So just forget about the @public compiler directive. The default
setting of @protected will serve you in the vast majority of cases.
The @private directive does have its place, though. You would use @private if you don't
want the instance variable inherited by subclasses. Perhaps you don't want a subclass
monkeying with a variable that is key to the architecture of the base class. Or perhaps
you want to minimize the dependencies between the base and sub classes. Though
@private does have its place, don't use it unless you absolutely have a reason to. The
general opinion seems to hold that you should never use @private at all -- that all
classes should have all functionality overridable. Just wanted to make sure you heard
both sides...
Here's an example that uses all three directives:
@interface Employee : Object
@private
int yearsWithCompany;
int hoursVacation;
@protected
char *title;
@public
id supervisor;
id officeMate;
}
The @public, @private, and @protected compiler directives hold true for all instance
variables that follow until either the end of the class or another directive is
encountered. In the example above, the name variable is @protected, since it is not
marked otherwise. yearsWithCompany and hoursVacation are @private, title is
protected, and supervisor and officeMate are public. Of course, this sample was just to
show you how this works and is not intended as realistic code.
Bottom line, your best bet is to leave these directives out of your code and just use the
default setting of @protected. On the other hand, it is worth knowing how this works so
you can read sample code that uses it and so you can use @private if you find a case
where it makes sense.
Init vs. Init:
In last month's column, we looked at a sample program that included a simple class
named Number. Here's the Number implementation:
#import "Number.h
@implementation Number
- init:(int)startValue /* This is BAD FORM - see below */
value = startValue;
return self;
}