Definir sus métodos privados en el @implementationbloque es ideal para la mayoría de los propósitos. Clang los verá dentro del @implementation, independientemente del orden de la declaración. No es necesario declararlos en una continuación de clase (también conocida como extensión de clase) o categoría con nombre.
En algunos casos, deberá declarar el método en la continuación de la clase (por ejemplo, si usa el selector entre la continuación de la clase y el @implementation).
static Las funciones son muy buenas para métodos privados particularmente sensibles o críticos para la velocidad.
Una convención para nombrar prefijos puede ayudarlo a evitar anular accidentalmente métodos privados (encuentro el nombre de la clase como un prefijo seguro).
Las categorías con nombre (por ejemplo @interface MONObject (PrivateStuff)) no son una idea particularmente buena debido a posibles colisiones de nombres al cargar. En realidad, solo son útiles para métodos protegidos o amigos (que rara vez son una buena opción). Para asegurarse de que se le advierta sobre implementaciones de categoría incompletas, en realidad debería implementarlo:
@implementation MONObject (PrivateStuff)
...HERE...
@end
Aquí hay una pequeña hoja de trucos anotada:
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
Otro enfoque que puede no ser obvio: un tipo C ++ puede ser muy rápido y proporcionar un grado de control mucho mayor, al tiempo que minimiza el número de métodos objc exportados y cargados.