Objective-С (middle level) Вступ до патернів.

Цей цикл статтей розрахований на людей, які вже добре обізнані з Objective-С (не впевнений, що на даному етапі я можу про себе таке сказати, але мені завжди було цікаво ознайомитись з патернами).
ПіонЕрами в цій справі була "фантастична четвірка" , "Gang of Four" - банда чотирьох. Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma,
Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley Professional, 1994) http://en.wikipedia.org/wiki/Design_Patterns .

Своій погляд стосовно даної тематики я зупинив на Carlo Chung (Apress) - Pro Objective-C Design Patterns for iOS - 2011.
Що ж таке патерн? На даний момент я зрозумів, що часто приходиться писати багато схожого коду, і в розробників виникає свого роду Déjà-vu.
Тому для вирішення практично схожих задач створили свого роду узагальненний розв'язок, який і носить назву патерн. Трактування "так собі", для отримання більш академічного гугл в поміч. 

Я впевнений, що при слові Déjà-vu, всі згадали "Матрицю": в певному розумінні там використовували поняття патерну, коли злий агент Сміт переписував код будинку використовуючи інші готові блоки... Були двері, нема дверей і потипу того, можливо брати Вачовські начитались страшних книжок по патернах, і їх як накрило гієною вогняною з ноликів і одиничок, як побачили вони силу сінглітону, ітератору, фабричого методу і єже з ним.  Чого коштують три матриці, "Асасін" та "Ніндзя асасін"?! Подивившись ці фільми, можна зрозуміти, що програмування з використанням патернів по різному може впливати на психіку і свідомість людей.  

Виходячи з практики "банди чотирьох", необхідно писати програми за таким принципом: Program to an interface, not an implementation. В програмах необхідно застосовувати узагальнені інтерфейси і вже з них вибудовувати саму архітектуру, а не спиратися на чітко заточені об'єкти. Це сприяє більшій гнучкості написаного коду та можливості його швидкої і якісної заміни.
В Objective-C для роботи з інтерфейсом  існують два підходи. Перший - це @protocol. Тут  ви можете описати методи, які будете використовувати, без будь-якої їх реалізації. Другий - абстрактний клас, в якому деякі класи можуть або є не реалізовані. Вони мають бути переписані в класах - наслідниках. Проте, проблемою протоколу та  абстрактного класу є те, що при зміні назви методу або данних  необхідно ввести зміни в усих класах, які наслідують цей протокол чи абстрактний клас, вихід є ім'я йому @optional. Застосовуючи це "чарівне" слово, ВИ зможете спокійно змінювати протокол, не переживаючи, що компілятор буде видавати вам повідомлення про те, що ви не заімпліментили якийсь метод.

Приклади беруться все з тієї ж книжки, тому не судіть строго.
Значить, припустимо, в нас є @protocol Mark
Вам необхідно звернутися до будь-якого об'єкту, цього типу.
id <Mark> thisMark;
Виклик методу буде виглядати, як 
- (void) anOperationWithMark:(id <Mark>) aMark;
Якщо це абстрактний клас, то це матиме інший вигляд.

Mark *thisMark;

- (void) anOperationWithMark:(Mark *) aMark;
Може здатися, що використовувати протоколи не дуже зручно, проте, є дуже багато ситуацій, коли необхідно просто "підмішати" деякому класу певних властивостей, для його кращої роботи, що не можна зробити застосовуючи абстрактні класи, які необхідно наслідувати.

Далі буде...