Das Definieren Ihrer privaten Methoden im @implementationBlock ist für die meisten Zwecke ideal. Clang sieht diese innerhalb der @implementation, unabhängig von der Reihenfolge der Deklaration. Es ist nicht erforderlich, sie in einer Klassenfortsetzung (auch als Klassenerweiterung bezeichnet) oder einer benannten Kategorie zu deklarieren.
In einigen Fällen müssen Sie die Methode in der Klassenfortsetzung deklarieren (z. B. wenn Sie den Selektor zwischen der Klassenfortsetzung und der verwenden @implementation).
static Funktionen sind sehr gut für besonders empfindliche oder geschwindigkeitskritische private Methoden.
Eine Konvention zum Benennen von Präfixen kann Ihnen dabei helfen, ein versehentliches Überschreiben privater Methoden zu vermeiden (ich finde den Klassennamen als Präfix sicher).
Benannte Kategorien (z. B. @interface MONObject (PrivateStuff)) sind wegen möglicher Namenskollisionen beim Laden keine besonders gute Idee. Sie sind wirklich nur für Freunde oder geschützte Methoden nützlich (die sehr selten eine gute Wahl sind). Um sicherzustellen, dass Sie vor unvollständigen Kategorieimplementierungen gewarnt werden, sollten Sie diese tatsächlich implementieren:
@implementation MONObject (PrivateStuff)
...HERE...
@end
Hier ist ein kleiner kommentierter Spickzettel:
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
Ein weiterer Ansatz, der möglicherweise nicht offensichtlich ist: Ein C ++ - Typ kann sowohl sehr schnell sein als auch ein viel höheres Maß an Kontrolle bieten und gleichzeitig die Anzahl der exportierten und geladenen Objektmethoden minimieren.