CODEWITHSUNDEEP
iphoneobjective-cipadcocoa-touch
user594161
user594161

Reputation:

When Should You Add Methods To A Private Interface?

So I've recently been using more private interfaces in my classes. I've been leaving the stuff that is needed by other classes in the .h (public), and then keeping all other methods in the private interface in the .m. My question is, I don't see any reason to keep any methods in my private interface as the app works fine without this. What is really the point? Any why aren't system methods like viewDidLoad in the private interface?

Upvotes: 3

Views: 91

Answers (2)

rmaddy
rmaddy

Reputation: 318824

Adding method declarations in a private category is obsolete with the latest LLVM compiler. It used to be that methods had to be implemented in the proper order or you could add method declarations in a private category in the .m file. The latest compiler precludes the need for this. The new compiler does a 2-pass compile so it knows about all methods.

So the short answer to your question is - never. :)

Edit: Here's some sample code to reflect the ongoing discussion to this answer:

In the .h file:

// Only public stuff here
@interface Foo
- (void)somePublicMethod;
@end

In the .m file:

// private additions - clients don't need to know about this stuff
@interface Foo () <UIActionSheetDelegate, UIPickerViewDelegate>
@property (nonatomic) UIPickerView *pickerView; // private property
@end

@implementation Foo {
    UIActioSheet *_myActionSheet; // private ivar
}

- (void)somePrivateMethod {
    [self anotherPrivateMethod]; // yeah - I can call methods further down in the class
}

- (void)anotherPrivateMethod {
}
@end

Upvotes: 3

justin
justin

Reputation: 104698

So I've recently been using more private interfaces in my classes. I've been leaving the stuff that is needed by other classes in the .h (public), and then keeping all other methods in the private interface in the .m.

That's perfect. In some cases, you will want to use naming conventions or prefixes to avoid naming collisions. Moving on…

My question is, I don't see any reason to keep any methods in my private interface as the app works fine without this. What is really the point?

Encapsulation. Hide your data and implementation from your clients (and even subclasses) in order to minimize the side effects of any changes you must make. If the client really only needs 3 methods in the public interface -- declare only those 3 methods. Keep the remainder of the implementation details private to the class. When you don't use this, mutant implementations tend to multiply where clients use these unnecessary methods. Which means that when you need to change something, you will have a ton of detail to review across several source files (and apps, if you write libraries). A class' public interface is a good area to focus on being minimal.

Any why aren't system methods like viewDidLoad in the private interface?

viewDidLoad was designed to be overridden by subclasses, where necessary. Its declaration is public for 2 primary reasons:

  • Documentation. Your implementations will need this initialization step, and you need to know how to override it correctly.
  • So you can write [super viewDidLoad], and the compiler can be assured you are doing the right thing. If UIViewController had not declared it as an instance method, there would be at least one compiler warning.

Upvotes: 0

Related Questions