Meilleure façon de définir les méthodes privées pour une classe Objective-C

Il n'est pas vraiment une "méthode" en Objective-C, si le moteur d'exécution peuvent travailler sur la mise en œuvre de l'utilisation qu'il va faire. Mais cela ne veut pas dire qu'il n'y a pas de méthodes qui ne font pas partie de la documentation de l'interface. Pour ces méthodes, je pense qu'une catégorie est très bien. Plutôt que de mettre le @interface en haut de l' .m fichier comme votre point 2, je l'avais mis dans son propre .h fichier. Une convention que j'ai suivi (et qui en ont vu d'ailleurs, je pense que c'est une Pomme convention de Xcode offre désormais une prise en charge automatique) est le nom d'un tel fichier après sa catégorie et de catégorie a + de la séparation, de sorte @interface GLObject (PrivateMethods) peut être trouvé dans GLObject+PrivateMethods.h. La raison de l'en-tête de fichier est de sorte que vous pouvez l'importer dans votre unité de classes de test :-).

Par la façon dont, dans la mesure de mise en œuvre/définition des méthodes de près de la fin de la .m fichier est concerné, vous pouvez le faire avec une catégorie par la mise en œuvre de la catégorie en bas de la .m fichier:

@implementation GLObject(PrivateMethods)
- (void)secretFeature;
@end

ou avec une extension de classe (la chose que vous appelez une "catégorie vide"), il suffit de définir ces méthodes dernier. Objective-C méthodes peuvent être définis et utilisés dans n'importe quel ordre dans la mise en œuvre, donc il n'y a rien pour vous empêcher de vous mettre le "privé" des méthodes à la fin du fichier.

Même avec les extensions de la classe, je vais souvent créer un en-tête (GLObject+Extension.h) afin que je puisse utiliser ces méthodes si nécessaire, imitant "ami" ou "protégé" de la visibilité.

Depuis cette réponse a été écrit à l'origine, le compilateur clang a commencé à faire deux passes pour Objective-C méthodes. Cela signifie que vous pouvez éviter de déclarer votre "privé" méthodes complètement, et qu'ils soient au-dessus ou au-dessous de la vocation du site, ils vont être trouvée par le compilateur.

La définition de vos méthodes privées dans le @implementation bloc est idéal pour la plupart des besoins. Clang va voir à l'intérieur de la @implementation, indépendamment de leur ordre de déclaration. Il n'est pas nécessaire de les déclarer dans une classe de continuation (aka extension de classe) ou le nom de la catégorie.

Dans certains cas, vous aurez besoin de déclarer la méthode dans la classe de poursuite (par exemple, si vous utilisez le sélecteur entre la classe de la poursuite et de la @implementation).

static fonctions sont très bon pour la particulièrement sensibles ou de la vitesse critique des méthodes privées.

Une convention pour nommer les préfixes peuvent vous aider à éviter accidentellement prépondérant méthodes (je trouve le nom de la classe comme un préfixe de sécurité).

Nommé catégories (par exemple,@interface MONObject (PrivateStuff)) ne sont pas une très bonne idée à cause des conflits de noms lors du chargement. Ils sont vraiment utile pour un ami ou protégés des méthodes (qui sont très rarement un bon choix). Pour vous assurer que vous êtes averti du caractère incomplet de la catégorie des implémentations, en fait, vous devez la mettre en œuvre:

@implementation MONObject (PrivateStuff)
...HERE...
@end

Voici un petit annoté feuille de triche:

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 ne peut pas être évident: d'un C++ de type peut être à la fois très rapide et fournir un degré beaucoup plus élevé de contrôle, tout en minimisant le nombre de exportés et chargé objc méthodes.

Vous pouvez utiliser des blocs?

@implementation MyClass

id (^createTheObject)() = ^(){ return [[NSObject alloc] init];};

NSInteger (^addEm)(NSInteger, NSInteger) =
^(NSInteger a, NSInteger b)
{
    return a + b;
};

//public methods, etc.

- (NSObject) thePublicOne
{
    return createTheObject();
}

@end

Je suis conscient que c'est une vieille question, mais c'est un des premiers que j'ai découvert lorsque j'étais à la recherche d'une réponse à cette question. Je n'ai pas vu cette solution discuté nulle part ailleurs, alors laissez-moi savoir si il y a quelque chose de stupide à ce sujet.

Si vous avez voulu éviter la @interface bloc en haut, vous pouvez toujours mettre le privé déclarations dans un autre fichier MyClassPrivate.h pas l'idéal mais ce n'est pas encombrer la mise en œuvre.

MyClass.h

interface MyClass : NSObject {
 @private
  BOOL publicIvar_;
  BOOL privateIvar_;
}

@property (nonatomic, assign) BOOL publicIvar;
//any other public methods. etc
@end

MyClassPrivate.h

@interface MyClass ()

@property (nonatomic, assign) BOOL privateIvar;
//any other private methods etc.
@end

MyClass.m

#import "MyClass.h"
#import "MyClassPrivate.h"
@implementation MyClass

@synthesize privateIvar = privateIvar_;
@synthesize publicIvar = publicIvar_;

@end

Il n'y a aucun moyen de se déplacer à la question 2. C'est juste la façon dont le compilateur C (et donc de l'Objective-C compilateur) de travail. Si vous utilisez le XCode éditeur, la fonction popup devrait rendre facile pour naviguer dans le @interface et @implementation blocs dans le fichier.

Que d'autres personnes, a déclaré la définition des méthodes privées dans le @implementation bloc est OK pour la plupart des besoins.

Sur le thème de la code de l'organisation - je tiens à les garder sous pragma mark private pour faciliter la navigation dans Xcode

@implementation MyClass 
//.. public methods

# pragma mark private 
//...

@end