Re: required in .h
Re: required in .h
- Subject: Re: required in .h
- From: "Michael B. Johnson" <email@hidden>
- Date: Tue, 28 Aug 2001 22:32:07 -0700
On Tuesday, August 28, 2001, at 09:11 PM, From: Chris Gehlker
<email@hidden> wrote:
On 8/28/01 3:35 PM, "Stuppel, Searle @ San Diego Central"
<email@hidden> wrote:
What exactly is required in a .h file?
I know this is probably a basic question, but after a long time of
messing
with it, my guess comes down to: Only stuff that other files need to be
able
to "see".
In other words:
- (BOOL)validateMenuItem:(NSMenuItem *)anItem; is not needed in a .h
- (void)awakeFromNib; is not needed in a .h
Can someone give me a hard and fast rule for this if such exists?
The good practice rule is that every method and every function should be
in
a .h file.
I *strongly* disagree with this. The public interface of the class should
be in the header file - and that's it. Whatever's in the header file will
probably *become* the public API, so best to plan for it. I will almost
always (certainly for any non-trivial classes) have a raft of private
helper methods in my class that I use to simplify or streamline the
current implementation of the public methods, but that I don't want to
expose as public API (because once I do, I'm stuck with it).
The ones Apple supplies are already in Cocoa.h so you don't need
to mention them again in your own .h file. That's why validateMenuItem:
and
awakeFromNib don't need to be in your .h file.
I can go either way on this - some people like to know what stuff is
getting overridden in a subclass by looking at the header file - I'm
usually one of those people.
Again, in general, I think of the header file as the one true
documentation for my class for anyone that can't or won't be able to look
at the implementation, and so should only reflect the API I'm willing to
live with forever.
--> Michael B. Johnson, Ph.D. -- email@hidden
--> Studio Tools, Pixar Animation Studios
-->
http://xenia.media.mit.edu/~wave