tags:

views:

951

answers:

3

I'm seeing some code I've inherited that looks like the following:

@interface SomeClass (private)

This is within SomeClass.m, the implementation file. There is an accompanying header file which doesn't suggest that the class is using a category. Is (private) in this case just a poor name given to a category for SomeClass? And I'm assuming it's perfectly legitimate to specify categories such as these in an implementation?

+2  A: 

"Private" is just a name that suggests the methods are not public and are used for the internal implementation of the class, but there's nothing in the declaration of the category that enforces that.

Also, methods defined in a category are added to the class definition at runtime, so the accompanying header file need not declare that it is using a category -- it gets "used" automatically.

mipadi
+1  A: 

I use that to give me somewhere to declare (and thus document, as well as shut the compiler up about) helper methods which don't need to be in the public interface. Then the "consumers" of the class are (tacitly, given that there's nothing stopping them other than good manners) restricted to using methods defined in the header file.

Graham Lee
+11  A: 

It isn't the name "private" that makes it private; the methods are private because they are in a category declared within the implementation file.

There are three uses of a category, each of which add methods to a class (note: methods only, not iVars)

Extending an existing Cocoa class

This lets you add your own methods to an existing class. For example, if you want to extend NSString to apply special capitalisationyou could create a new class called, say NSString+Capitals. in the NSString+Capitals.h you would have:

@interface NSString (Capitals)

-(NSString *)alternateCaps:(NSString *)aString;

@end

and in NSString+Capitals.m you would implement the method

@implementation NSString (Capitals)
-(NSString *)alternateCaps:(NSString *)aString
{
    // Implementation
}

Private methods on a class

This is the same as above, except that the extra methods are declared and defined in the implementation file (.m) Usually a way of having private methods - because they are not in the .h file (which is the one #imported by other classes) they are simply not visible. In this case, the implementation of the methods are done in their own implementation block. e.g

// someClass.m
@interface someClass (extension)
-(void)extend;
@end

@implementation someClass
    // all the methods declared in the .h file and any superclass
    // overrides in this block
@end

@implementation someClass (extension)
-(void)extend {
    // implement private method here;
}

Class Extension (New for 10.5 Leopard)

A simpler way of having private methods. In this special case, the category name is empty and the private methods are implemented in the same block as all the other class methods.

// someClass.m
@interface someClass ()
-(void)extend;
@end

@implementation someClass
    // all the methods declared in the .h file and any superclass
    // overrides in this block
    // Implement private methods in this block as well.
-(void)extend {
    // implement private method here;
}

@end

Here's a link to the Apple docs on Categories and extensions.

Abizern
I disagree that you should mix private (category) methods with your regular implementation. It's a matter of style, but I like to maintain a clear separation.
Marc Charbonneau
It's worth noting that the class continuation (what you call a class extension) is new in Leopard.
Peter Hosey
@Peter. Thanks for pointing that out.@Marc. In the case where the category is empty, the methods must be implemented in the main block. However, when using the second method, I agree that it's better style to put category implementations in their own block.
Abizern