Чи можливо зробити метод -init приватним в Objective-C?

Мені потрібно сховати (зробити приватним) -initметод мого класу в Objective-C.

Як я можу це зробити?

Objective-C, як і Smalltalk, не має поняття "приватні" проти "публічних" методів. Будь-яке повідомлення можна надіслати будь-якому об’єкту в будь-який час.

Що ви можете зробити, це кинути, NSInternalInconsistencyExceptionякщо ваш -initметод викликається:

- (id)init {
    [self release];
    @throw [NSException exceptionWithName:NSInternalInconsistencyException
                                   reason:@"-init is not a valid initializer for the class Foo"
                                 userInfo:nil];
    return nil;
}

Інша альтернатива - що, мабуть, набагато краще на практиці - полягає в тому, щоб -initзробити щось розумним для свого класу, якщо це взагалі можливо.

Якщо ви намагаєтеся це зробити, тому що ви намагаєтеся "забезпечити" використання однотонного об'єкта, не турбуйтеся. В Зокрема, не морочитися з «перевизначення +allocWithZone:, -init, -retain, -release» метод створення одинаків. Це практично завжди непотрібно і просто додає ускладнень без жодної реальної суттєвої переваги.

Натомість просто запишіть свій код таким чином, щоб ваш +sharedWhateverметод був таким, як ви отримуєте доступ до синглтона, і документуйте це як спосіб отримати одиночний екземпляр у своєму заголовку. Це повинно бути все, що вам потрібно в переважній більшості випадків.

NS_UNAVAILABLE

- (instancetype)init NS_UNAVAILABLE;

Це коротка версія недоступного атрибута. Вперше він з'явився в macOS 10.7 та iOS 5 . Це визначено в NSObjCRuntime.h як #define NS_UNAVAILABLE UNAVAILABLE_ATTRIBUTE.

Існує версія, яка вимикає метод лише для клієнтів Swift , а не для коду ObjC:

- (instancetype)init NS_SWIFT_UNAVAILABLE;

unavailable

Додайте unavailableатрибут до заголовка, щоб створити помилку компілятора при будь-якому виклику до init.

-(instancetype) init __attribute__((unavailable("init not available")));  

Якщо у вас немає причини, просто введіть __attribute__((unavailable))або навіть __unavailable:

-(instancetype) __unavailable init;  

doesNotRecognizeSelector:

Використовуйте doesNotRecognizeSelector:для підняття NSInvalidArgumentException. "Система виконання викликає цей метод, коли об'єкт отримує повідомлення aSelector, на яке він не може відповісти або переслати."

- (instancetype) init {
    [self release];
    [super doesNotRecognizeSelector:_cmd];
    return nil;
}

NSAssert

Використовуйте, NSAssertщоб кинути NSInternalInconsistencyException і показати повідомлення:

- (instancetype) init {
    [self release];
    NSAssert(false,@"unavailable, use initWithBlah: instead");
    return nil;
}

raise:format:

Використовуйте, raise:format:щоб кинути власний виняток:

- (instancetype) init {
    [self release];
    [NSException raise:NSGenericException 
                format:@"Disabled. Use +[[%@ alloc] %@] instead",
                       NSStringFromClass([self class]),
                       NSStringFromSelector(@selector(initWithStateDictionary:))];
    return nil;
}

[self release]потрібен тому, що об’єкт вже був allocз'їденим. Під час використання ARC компілятор зателефонує за вас. У будь-якому випадку, не про що потрібно хвилюватися, коли ви збираєтесь навмисно зупинити страту.

objc_designated_initializer

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

-(instancetype)myOwnInit NS_DESIGNATED_INITIALIZER;

Це генерує попередження, якщо будь-який інший метод ініціалізатора не викликає myOwnInitвнутрішньо. Деталі будуть опубліковані у прийнятті Modern Objective-C після наступного випуску Xcode (я думаю).

Apple почала використовувати наступне у своїх заголовкових файлах, щоб відключити конструктор init:

- (instancetype)init NS_UNAVAILABLE;

Це правильно відображається як помилка компілятора в Xcode. Зокрема, це встановлено в декількох файлах заголовків HealthKit (HKUnit є одним з них).

Якщо ви говорите про метод -init за замовчуванням, ви не можете. Він успадкований від NSObject, і кожен клас відповість на нього без попереджень.

Ви можете створити новий метод, скажімо -initMyClass, і помістити його в приватну категорію, як пропонує Метт. Потім визначте метод -init за замовчуванням, щоб підняти виняток, якщо він викликається або (краще) викликати ваш приватний -initMyClass з деякими значеннями за замовчуванням.

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

Помістіть це у файл заголовка

- (id)init UNAVAILABLE_ATTRIBUTE;

Ви можете оголосити будь-який метод недоступним за допомогою NS_UNAVAILABLE.

Таким чином, ви можете розмістити ці рядки під своїм інтерфейсом @

- (instancetype)init NS_UNAVAILABLE;
+ (instancetype)new NS_UNAVAILABLE;

Ще краще визначте макрос у заголовку префікса

#define NO_INIT \
- (instancetype)init NS_UNAVAILABLE; \
+ (instancetype)new NS_UNAVAILABLE;

і

@interface YourClass : NSObject
NO_INIT

// Your properties and messages

@end

Це залежить від того, що ви маєте на увазі під «зробити приватним». У Objective-C виклик методу на об'єкт може бути краще описаний як відправка повідомлення цьому об’єкту. У мові немає нічого, що забороняє клієнту викликати будь-який заданий метод на об'єкт; найкраще, що ви можете зробити, це не оголосити метод у файлі заголовка. Якщо клієнт все-таки зателефонує "приватному" методу з правильним підписом, він все одно буде виконуватися під час виконання.

Однак, найпоширеніший спосіб створення приватного методу в Objective-C - це створення Категорії у файлі реалізації та оголошення всіх «прихованих» методів. Пам’ятайте, що це по-справжньому не завадить initзапускати дзвінки , але компілятор випустить попередження, якщо хтось спробує це зробити.

MyClass.m

@interface MyClass (PrivateMethods)
- (NSString*) init;
@end

@implementation MyClass

- (NSString*) init
{
    // code...
}

@end

На цій темі на MacRumors.com є гідна нитка .

ну проблема, чому ви не можете зробити його "приватним / невидимим", полягає в тому, що метод init отримує пересилання в id (як аллок повертає ідентифікатор) не в YourClass

Зауважте, що з точки зору компілятора (перевірки) ідентифікатор може потенційно відповідати на все, що коли-небудь вводиться (він не може перевірити, що насправді йде в ідентифікатор під час виконання), тож ви можете ховати init лише тоді, коли нічого нікуди не буде (public = in заголовок) використовуйте метод init, ніж компілятор знав би, що ідентифікатор не може реагувати на init, оскільки ніде не існує init (у вашому джерелі, всі libs тощо ...)

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

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

static SomeClass * SInstance = nil;

- (id)init
{
    // possibly throw smth. here
    return nil;
}

- (id)initOnce
{
    self = [super init];
    if (self) {
        return self;
    }
    return nil;
}

+ (SomeClass *) shared 
{
    if (nil == SInstance) {
        SInstance = [[SomeClass alloc] initOnce];
    }
    return SInstance;
}

Зауважте: хтось міг це зробити

SomeClass * c = [[SomeClass alloc] initOnce];

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

ми могли б ще більше запобігти цьому, але в цьому немає потреби

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

Я б рекомендував використовувати __unavailableяк пояснив Джано для свого першого прикладу .

Методи можуть бути відмінені в підкласах. Це означає, що якщо метод у надкласі використовує метод, який просто викликає виняток у підкласі, він, ймовірно, не працюватиме за призначенням. Іншими словами, ви просто зламали те, що раніше працювали. Це справедливо і для методів ініціалізації. Ось приклад такої досить поширеної реалізації:

- (SuperClass *)initWithParameters:(Type1 *)arg1 optional:(Type2 *)arg2
{
    ...bla bla...
    return self;
}

- (SuperClass *)initWithLessParameters:(Type1 *)arg1
{
    self = [self initWithParameters:arg1 optional:DEFAULT_ARG2];
    return self;
}

Уявіть, що станеться з -initWithLessParameters, якщо я це роблю в підкласі:

- (SubClass *)initWithParameters:(Type1 *)arg1 optional:(Type2 *)arg2
{
    [self release];
    [super doesNotRecognizeSelector:_cmd];
    return nil;
}

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

Це також означає, що ви можете використовувати твердження та винятки в методах, які необхідно перекрити в підкласах. ("Абстрактні" методи, як у створенні абстрактного класу в Objective-C )

І не забувайте про метод + новий клас.