La définition de vos méthodes privées dans le @implementationbloc est idéale dans la plupart des cas. Clang les verra dans @implementation, indépendamment de l'ordre de déclaration. Il n'est pas nécessaire de les déclarer dans une continuation de classe (aka extension de classe) ou une catégorie nommée.
Dans certains cas, vous devrez déclarer la méthode dans la continuation de classe (par exemple si vous utilisez le sélecteur entre la continuation de classe et le @implementation).
static les fonctions sont très bonnes pour les méthodes privées particulièrement sensibles ou sensibles à la vitesse.
Une convention pour nommer les préfixes peut vous aider à éviter d'écraser accidentellement les méthodes privées (je trouve le nom de classe comme un préfixe sûr).
Les catégories nommées (par exemple @interface MONObject (PrivateStuff)) ne sont pas une bonne idée en raison des collisions de noms potentielles lors du chargement. Ils ne sont vraiment utiles que pour les méthodes amis ou protégées (qui sont très rarement un bon choix). Pour vous assurer d'être averti des implémentations de catégorie incomplètes, vous devez réellement l'implémenter:
@implementation MONObject (PrivateStuff)
...HERE...
@end
Voici un petit aide-mémoire annoté:
MONObject.h
@interface MONObject : NSObject
// public declaration required for clients' visibility/use.
@property (nonatomic, assign, readwrite) bool publicBool;
// public declaration required for clients' visibility/use.
- (void)publicMethod;
@end
MONObject.m
@interface MONObject ()
@property (nonatomic, assign, readwrite) bool privateBool;
// you can use a convention where the class name prefix is reserved
// for private methods this can reduce accidental overriding:
- (void)MONObject_privateMethod;
@end
// The potentially good thing about functions is that they are truly
// inaccessible; They may not be overridden, accidentally used,
// looked up via the objc runtime, and will often be eliminated from
// backtraces. Unlike methods, they can also be inlined. If unused
// (e.g. diagnostic omitted in release) or every use is inlined,
// they may be removed from the binary:
static void PrivateMethod(MONObject * pObject) {
pObject.privateBool = true;
}
@implementation MONObject
{
bool anIvar;
}
static void AnotherPrivateMethod(MONObject * pObject) {
if (0 == pObject) {
assert(0 && "invalid parameter");
return;
}
// if declared in the @implementation scope, you *could* access the
// private ivars directly (although you should rarely do this):
pObject->anIvar = true;
}
- (void)publicMethod
{
// declared below -- but clang can see its declaration in this
// translation:
[self privateMethod];
}
// no declaration required.
- (void)privateMethod
{
}
- (void)MONObject_privateMethod
{
}
@end
Une autre approche qui peut ne pas être évidente: un type C ++ peut être à la fois très rapide et fournir un degré de contrôle beaucoup plus élevé, tout en minimisant le nombre de méthodes objc exportées et chargées.