6

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?

Abizern
  • 146,289
  • 39
  • 203
  • 257
Coocoo4Cocoa
  • 48,756
  • 50
  • 150
  • 175

3 Answers3

30

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 capitalization, you 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
  • 146,289
  • 39
  • 203
  • 257
  • 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 Dec 11 '08 at 22:51
  • It's worth noting that the class continuation (what you call a class extension) is new in Leopard. – Peter Hosey Dec 11 '08 at 22:51
  • @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 Dec 12 '08 at 00:00
  • This was helpful a lot for me. In xcode do you recommend putting category files in the Models folder or in the Supporting Files? – JohnMerlino Mar 09 '12 at 21:40
  • @JohnMerlino I put them in a group called Categories if they are extensions system classes. In the rare cases where I create a category of my own class I just keep them in the same place as the class they are categories of. – Abizern Mar 09 '12 at 22:23
2

"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
  • 398,885
  • 90
  • 523
  • 479
2

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.