Паттерны ООП для iOS

Порождающие паттерны (creational) делают систему независимой от способа создания объектов:

• Одиночка (singleton)
  
• Абстрактная фабрика (abstract factory)
  

Структурные паттерны (structural) ищут простые способы наглядно представить связи между объектами:

• MVC (спорная классификация, ну пусть будет тут. — Прим. пер.)
  
• Декоратор (decorator)
  
• Адаптер (adapter)
  
• Фасад (facade)
  
• Компоновщик (composite)
  

Поведенческие паттерны (behavioral) определяют сам процесс взаимодействия, «общения» между объектами:

• Наблюдатель (observer)
  
• Хранитель (memento)
  
• Цепочка ответственности (chain of responsibility)
  
• Команда (command)

MVC — король паттернов

• Модель уведомляет контроллер о любых изменениях в данных. В свою очередь, контроллер обновляет данные в представлениях.
  
• Представление уведомляет контроллер о действиях пользователя. Контроллер по необходимости обновляет модель или получает запрошенные данные.

 Вопрос сводится к двум (взаимосвязанным) вещам:

1. Разделение кода;
2. Перспектива повторного использования кода.

Одиночка (синглтон)

 Паттерн «одиночка» гарантирует, что во всём приложении существует только один экземпляр данного класса. Существует глобальная точка доступа к этому экземпляру. Обычно применяется отложенная инициализация: этот единственный экземпляр создаётся, когда он нужен в первый раз.

+ (LibraryAPI *)sharedInstance
{
    // Объявляем статическую переменную для хранения указателя на экземпляр класса (её значение будет доступно глобально из нашего класса).
    static LibraryAPI * _sharedInstance = nil;

    // Объявляем статическую переменную dispatch_once_t, которая обеспечит, что код инициализации будет выполнен только один раз.
    static dispatch_once_t oncePredicate;

    // При помощи Grand Central Dispatch (GCD) выполняем инициализацию экземпляра LibraryAPI. В этом суть паттерна «одиночка»: блок инициализации никогда не выполнится повторно.
    dispatch_once(&oncePredicate, ^{
        _sharedInstance = [[LibraryAPI alloc] init];
    });
    return _sharedInstance;
}

При повторном вызове sharedInstance() код внутри блока dispatch_once не будет выполнен (т.к. он уже выполнен ранее), и вы получите указатель на предыдущий созданный экземпляр LibraryAPI

Фасад

Паттерн «Фасад» предоставляет единый интерфейс к сложной подсистеме. Чтобы не шокировать юзеров множеством классов с разными интерфейсами, мы предоставляем один простой API:

 

 

@interface LibraryAPI ()
{
    PersistencyManager * persistencyManager;
    HTTPClient * httpClient;
    BOOL isOnline;
}

Примечание: HTTP-клиент у нас не будет работать с реальным сервером. Он присутствует здесь только для демонстрации паттерна «Фасад».  

Взгляните на метод addAlbum:atIndex:. Сначала он обновляет данные локально, а затем, если есть подключение к интернету, обновляет данные на удалённом сервере. Это реальное  преимущество «Фасада»: когда какой-нибудь класс за пределами Солнечной системы добавляет новый альбом, он не знает — и не должен знать — о сложности того, что скрыто внутри.

Декоратор

Говоря умными словами, шаблон «Декоратор» динамически добавляет поведение (behaviors) и обязанности (responsibilities) к объекту, не меняя его код. Это альтернатива наследованию (при наследовании вы меняете поведение класса, обернув его в подкласс).

Категории

«Категория» (Category) — очень мощный механизм, позволяющий добавлять методы к существующим классам без наследования. Новые методы добавляются при компиляции и могут быть выполнены как обычные методы расширенного класса. Это немного отличается от классического определения «Декоратора», т.к. «Категория» не содержит экземпляр класса, который она расширяет.