Чому в Objective-C я повинен перевіряти, чи self = [super init] не є нульовим?

У мене загальне запитання щодо написання методів init в Objective-C.

Я бачу всюди (код Apple, книги, відкритий вихідний код тощо), що метод init повинен перевірити, чи self = [super init] не є нульовим, перш ніж продовжувати ініціалізацію.

Типовим шаблоном Apple для методу init є:

- (id) init
{
    self = [super init];

    if (self != nil)
    {
        // your code here
    }

    return self;
}

Чому?

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

Чи дійсно так часто, що метод init класу може повернути нуль? Якщо так, то в якому випадку і чому?

Наприклад:

[[NSData alloc] initWithContentsOfFile:@"this/path/doesn't/exist/"];
[[NSImage alloc] initWithContentsOfFile:@"unsupportedFormat.sjt"];
[NSImage imageNamed:@"AnImageThatIsntInTheImageCache"];

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

Ця ідіома є стандартною, оскільки вона працює у всіх випадках.

Нечасто, але бувають випадки, коли ...

[super init];

... повертає інший екземпляр, вимагаючи присвоїти себе.

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

Суть полягає в тому, що це задокументована правильна схема використання, і якщо ви її не використовуєте, ви робите це неправильно.

Я думаю, що в більшості класів, якщо значення повернення від [super init] дорівнює нулю, і ти перевіряєш його, як рекомендують стандартні практики, а потім повертається передчасно, якщо нуль, в основному ваш додаток все ще не працює належним чином. Якщо ви думаєте про це, не дивлячись на те, що якщо (саме! = Нуль) перевірка є, для правильної роботи вашого класу, 99,99% часу ви на самому справі робите потреба себе , щоб бути не дорівнює нулю. Тепер, припустимо, з будь-якої причини [super init] все- таки повернув нуль, в основному ваша перевірка проти нуля в основному передає долар абоненту вашого класу, де він, швидше за все, не вдасться, оскільки, природно, буде припускати, що дзвінок був успішний.

В основному, я отримую те, що 99,99% часу, якщо (self! = Nil) нічого не купує у плані більшої надійності, оскільки ви просто передаєте долар своєму провайдеру. Щоб реально впоратися з цим надійно, вам фактично потрібно було б встановити чеки у всій ієрархії викликів. І навіть тоді, єдине, що б вам придбало, - це те, що ваш додаток вийде з ладу трохи більш чисто / надійно. Але все-таки провалиться.

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

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

Але для коду рівня C я все одно перевіряю значення повернення malloc () проти покажчика NULL. Тоді як для Objective-C, поки не знайду доказів протилежного, я думаю, що я пропускаю перевірки if (self! = Nil). Чому невідповідність?

Тому що на рівнях С і малок в деяких випадках ви можете частково відновитися. Хоча я думаю, що в Objective-C, в 99,99% випадків, якщо [super init] поверне нуль, ви в основному знаходяться, навіть якщо ви намагаєтеся впоратися з цим. Ви також можете просто дозволити програмі вийти з ладу і вирішити наслідки.

Це своєрідне резюме коментарів вище.

Скажімо, суперклас повертається nil. Що буде?

Якщо ви не дотримуєтесь конвенцій

Ваш код занепаде в середині вашого initметоду. (якщо тільки initнічого не означає)

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

Ваш код буде заборонено зламатись в якийсь момент пізніше, тому що ваш примірник там nil, де ви очікували чогось іншого. Або ваша програма буде вести себе несподівано, без збоїв. О Боже! Ви цього хочете? Не знаю...

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

У кодовій документації (!) Повинно бути чітко зазначено: "повертається ... або нуль", а решта вашого коду потрібно підготувати для цього. Тепер це має сенс.

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

І так, для запису я дотримуюсь найкращої практики і пишу її на всіх своїх заняттях, навіть тих, що походять безпосередньо з NSObject.

Ти маєш рацію, ти часто можеш просто писати [super init], але це не спрацює з підкласом просто нічого. Люди вважають за краще запам’ятати один стандартний рядок коду та використовувати його постійно, навіть коли це лише іноді необхідно, і, таким чином, ми отримуємо стандарт if (self = [super init]), який приймає як можливість повернення нуля, так і можливість об'єкта, відмінного від selfповернення в обліковому записі.

Поширена помилка - писати

self = [[super alloc] init];

який повертає екземпляр надкласу, який НЕ є тим, що потрібно у конструкторі / init підкласу. Ви повертаєте об’єкт, який не реагує на методи підкласу, що може заплутати, і створює заплутані помилки щодо невідповідності методам чи ідентифікаторам, які не знайдені тощо.

self = [super init]; 

потрібен, якщо в суперкласі є члени (змінні чи інші об'єкти), які слід ініціалізувати спочатку перед тим, як налаштувати членів підкласів. Інакше час виконання objc ініціалізує їх до 0 або до нуля . (на відміну від ANSI C, який часто виділяє шматки пам'яті, не очищаючи їх взагалі )

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

Це потрібно перевірити, чи працює інтіалазація, якщо оператор if повертає істину, якщо метод init не повернув нуль, тому його спосіб перевірити створення об'єкта працював правильно. Кілька причин, які я можу подумати, що ініт може зазнати невдачі, можливо, його переосмислений метод init, про який суперклас не знає, або щось подібне, я б не вважав, що це так часто. Але якщо це все-таки трапиться, то краще нічого не трапиться, щоб я зазнав аварії, тому її завжди перевіряють ...

В ОС X це не так вже ймовірно, що вона вийде -[NSObject init]з ладу через причини пам'яті. Те саме не можна сказати для iOS.

Крім того, це корисна практика для написання підкласингу класу, який може повернутися nilз будь-якої причини.