0

If you write method implementations in Objective-C, it is pretty standard to sum up the methods of a class in the corresponding @interface blocks. Publically accessible methods go in the header file's interface, not-so-public methods can go in an empty category on top of the implementation file.

But it's not neccessary to declare an interface for every method. If you only reference the methods below their implementation code of the same class/file, there's no need to put any declaration anywhere else.

-(void) doSomething {
}

-(void) doSomethingElse {
    [self doSomething];
}

Coming from another language, this is new to me. And I can't seem to decide whether it is nice and pretty to keep the interface blocks clean, or whether it should be prevented because the order of method implementations seem like a weird dependency to have.

What is the general public's opinion of this matter?

epologee
  • 11,229
  • 11
  • 68
  • 104

2 Answers2

1

The general rule I follow is that if the only method calling doSomething is doSomethingElse then it's fine to not have doSomething be part of the declared private interface. But the moment a second method makes use of doSomething I add it to the declared interface.

The thinking behind this is that as long as the method is only ever called from one place there's no reason to think of it as modular or reusable code. Instead it's more like the method exists just to tidy up the implementation of its calling method. In essence, the method doesn't really stand on its own, so there's no point in treating it like an interface method. But as soon as a second method is making the same call it demonstrates that the code is in fact reusable and useful in more than just the original context, and able to stand on its own as a useful function. So at that point, it becomes a declared part of the private interface.

aroth
  • 54,026
  • 20
  • 135
  • 176
  • I'd add to this that because of the way delegation works and the way that things are scheduled, you often end up with multiple methods representing a single flow of logic (such as, e.g. if you start on the main thread, performSelectorInBackground: to do something in the background, then performSelectorOnMainThread: to finish off with some quick UIKit or AppKit chatter). In that situation you explicitly don't want to advertise your implementation specifics, even to the rest of the implementation of your class. – Tommy Apr 18 '11 at 12:45
  • Tommy: If you believe that some set of implementation details is too specific for the rest of the class to know about then they should be part of another class. Not declaring something doesn't make it inaccessible (assuming you treat warnings as errors) to the rest of your implementation, just to an essentially random subset of it, and that's not a feature you want in a design. – smorgan Apr 18 '11 at 13:01
0

Some other coding style choices make answering this question really easy:

  • If you document every method at its declaration point, then not having a declaration means that either these methods are missing documentation, or they are documented at definition; either way it's inconsistent. If you follow the school of thought that most methods should be so self-explanatory from their name that they don't need documentation, this might not be an issue.

  • Some people advocate ordering methods from more general to more specific; in that model your example is ordered wrong, and the only way to fix it is to have a declaration.

There's also the question of whether you would find it annoying to get unexpected compiler errors when you do simple re-ordering or re-factoring just because you happened to start using a method earlier, and have to stop and add the declaration at that point.

smorgan
  • 20,228
  • 3
  • 47
  • 55