Найкращий спосіб визначення приватних методів для класу в Objective-C

Я щойно почав програмувати Objective-C і, маючи досвід роботи на Java, цікавлюсь, як люди, що пишуть програми Objective-C, мають справу з приватними методами.

Я розумію, що може бути декілька умов і звичок, і я розглядаю це питання як агрегатор кращих методів, якими користуються люди, що займаються приватними методами в Objective-C.

Будь ласка, додайте аргумент свого підходу, коли публікуєте його. Чому це добре? Які недоліки у нього є (які ви знаєте) і як ви з ними справляєтеся?

Щодо моїх висновків поки що.

Можна використовувати категорії [наприклад, MyClass (Private)], визначені у файлі MyClass.m, для групування приватних методів.

Цей підхід має 2 питання:

1. Xcode (і компілятор?) Не перевіряє, чи визначаєте ви всі методи в приватній категорії у відповідному блоці @implementation
2. Ви повинні поставити @interface, декларуючи вашу приватну категорію на початку файлу MyClass.m, інакше Xcode скаржиться на повідомлення типу "самовідвід не може відповісти на повідомлення" privateFoo ".

Перший випуск можна обійти з порожньою категорією [наприклад, MyClass ()].
Другий мене сильно турбує. Я хотів би бачити приватні методи, реалізовані (і визначені) наприкінці файлу; Я не знаю, чи це можливо.

Не існує, як уже говорили інші, такого поняття, як приватний метод в Objective-C. Однак, починаючи з Objective-C 2.0 (мається на увазі Mac OS X Leopard, iPhone OS 2.0 та пізніших версій), ви можете створити категорію з порожнім іменем (тобто @interface MyClass ()), що називається Розширення класу . Що стосується розширення класу, це те, що реалізація методу повинна @implementation MyClassвідповідати загальнодоступним методам. Тому я структурую свої класи так:

У файлі .h:

@interface MyClass {
    // My Instance Variables
}

- (void)myPublicMethod;

@end

І у файлі .m:

@interface MyClass()

- (void)myPrivateMethod;

@end

@implementation MyClass

- (void)myPublicMethod {
    // Implementation goes here
}

- (void)myPrivateMethod {
    // Implementation goes here
}

@end

Я думаю, що найбільшою перевагою такого підходу є те, що він дозволяє групувати реалізацію методу за функціональністю, а не за (іноді довільним) публічним / приватним розмежуванням.

Насправді не існує «приватного методу» в Objective-C, якщо час виконання може визначити, яка реалізація для його використання зробить це. Але це не означає, що не існує методів, які не входять до документально підтвердженого інтерфейсу. Для цих методів я вважаю, що категорія - це добре. Замість того, щоб розміщувати @interfaceу верхній частині файлу .m, як ваш пункт 2, я би розмістив його у власному .h-файлі. Конвенція, яку я дотримуюсь (і я бачила в іншому місці, я думаю, що це умова Apple, оскільки Xcode тепер надає автоматичну підтримку для неї) - це називати такий файл за його класом і категорією з +, що розділяє їх, тому @interface GLObject (PrivateMethods)його можна знайти в GLObject+PrivateMethods.h. Причина надання файлу заголовка полягає в тому, що ви можете імпортувати його у ваші тестові класи одиниці :-).

До речі, що стосується впровадження / визначення методів у кінці файлу .m, ви можете зробити це з категорією, застосувавши категорію внизу файлу .m:

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

або з розширенням класу (те, що ви називаєте "порожньою категорією"), просто визначте ці методи останніми. Методи Objective-C можуть бути визначені та використані в будь-якому порядку при здійсненні, тому нічого не зупинить вас, щоб ви поставили "приватні" методи в кінці файлу.

Навіть із розширеннями класу я часто створюю окремий заголовок ( GLObject+Extension.h), щоб я міг використовувати ці методи, якщо потрібно, імітуючи видимість "друг" або "захищений".

Оскільки ця відповідь була написана спочатку, компілятор clang почав робити два проходи для методів Objective-C. Це означає, що ви можете уникнути декларування своїх "приватних" методів повністю і незалежно від того, чи вони розташовані вище або нижче викличного сайту, їх знайде компілятор.

Поки я не фахівець Objective-C, я особисто просто визначаю метод у впровадженні свого класу. Зрозуміло, він повинен бути визначений до (вище) будь-яких методів, що викликають його, але для цього, безумовно, потрібна найменша кількість роботи.

Визначення ваших приватних методів у @implementationблоці ідеально підходить для більшості цілей. Кланг побачить їх всередині @implementation, незалежно від порядку декларації. Не потрібно оголошувати їх у продовженні класу (він же розширення класу) або в іменованій категорії.

У деяких випадках вам потрібно буде оголосити метод у продовженні класу (наприклад, якщо використовується перемикач між продовженням класу та the @implementation).

static функції дуже хороші для особливо чутливих або критичних швидкості приватних методів.

Конвенція про іменування префіксів може допомогти вам уникнути випадкового перекриття приватних методів (я вважаю ім'я класу безпечним для префікса).

Іменовані категорії (наприклад @interface MONObject (PrivateStuff)) не є особливо хорошою ідеєю через потенційні зіткнення імен при завантаженні. Вони дійсно корисні лише для друзів або захищених методів (які дуже рідко є хорошим вибором). Щоб упевнитись, що про неповні реалізації категорій вам потрібно реалізувати:

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

Ось невеликий анотований шпаргалка:

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

Ще один підхід, який може бути не очевидним: тип C ++ може бути дуже швидким і забезпечувати набагато більш високий ступінь контролю, мінімізуючи кількість експортованих та завантажених методів objc.

Ви можете спробувати визначити статичну функцію під або над вашою реалізацією, яка бере покажчик на ваш примірник. Він зможе отримати доступ до будь-яких змінних ваших примірників.

//.h file
@interface MyClass : Object
{
    int test;
}
- (void) someMethod: anArg;

@end


//.m file    
@implementation MyClass

static void somePrivateMethod (MyClass *myClass, id anArg)
{
    fprintf (stderr, "MyClass (%d) was passed %p", myClass->test, anArg);
}


- (void) someMethod: (id) anArg
{
    somePrivateMethod (self, anArg);
}

@end

Ви могли б використовувати блоки?

@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

Я знаю, що це старе питання, але це одне з перших, що я знайшов, коли шукав відповідь на це саме запитання. Я не бачив такого рішення, де обговорювались більше ніде, тому дайте мені знати, чи є щось дурне в цьому.

всі об'єкти в Objective C відповідають протоколу NSObject, який утримує метод PerformSelector:. Раніше я також шукав спосіб створити деякі "помічники чи приватні" методи, які мені не потрібні були відкритими на публічному рівні. Якщо ви хочете створити приватний метод без накладних витрат і не потрібно визначати його у своєму заголовковому файлі, тоді дайте це зйомки ...

визначте свій метод з аналогічним підписом, як код нижче ...

-(void)myHelperMethod: (id) sender{
     // code here...
}

тоді, коли вам потрібно посилатися на метод, просто викликайте його як селектор ...

[self performSelector:@selector(myHelperMethod:)];

цей рядок коду буде викликати створений вами метод і не матиме дратівливого попередження про невстановлення його у файлі заголовка.

Якщо ви хочете уникнути @interfaceблоку вгорі, ви завжди можете помістити приватні декларації в інший файл, MyClassPrivate.hне ідеальний, але це не захаращує реалізацію.

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

Ще одне, що я тут не бачив - Xcode підтримує .h файли з ім'ям "_private". Скажімо, у вас клас MyClass - у вас є MyClass.m та MyClass.h, і тепер ви також можете мати MyClass_private.h. Xcode розпізнає це та включить його до списку "Контрагентів" у помічнику редактора.

//MyClass.m
#import "MyClass.h"
#import "MyClass_private.h"

Не можна обійти питання №2. Ось так працює компілятор C (а значить і компілятор Objective-C). Якщо ви використовуєте редактор XCode, спливаюча функція повинна полегшувати навігацію @interfaceта @implementationблоки у файлі.

Є користь відсутності приватних методів. Ви можете перемістити логіку, яку ви хотіли приховати, до окремого класу та використовувати її як делегат. У цьому випадку ви можете позначити об’єкт делегування як приватний, і він не буде видно зовні. Перехід логіки до окремого класу (може бути декількох) робить кращим дизайн вашого проекту. Тому що ваші класи стають простішими, а ваші методи групуються в класи з власними іменами.

Як говорили інші, визначення приватних методів у @implementationблоці для більшості цілей добре.

Щодо теми організації коду - мені подобається тримати їх разом, pragma mark privateщоб полегшити навігацію в Xcode

@implementation MyClass 
// .. public methods

# pragma mark private 
// ...

@end