На связи Станислав Потемкин, iOS Tech Lead в компании Jivo.

Большой популярностью вполне заслуженно пользуются некоторые известные архитектурные паттерны, например универсальные MVC, MVP, MVVM, VIPER, и слегка платформенный Clean Swift (VIP).

У каждого из них свои особенности, каждый хорош в той или иной ситуации. Идеального для всех случаев инструмента, как известно, не существует: нужно выбирать с учётом проекта и команды.

На хабре уже была статья многолетней давности с неплохим разбором особенностей большинства этих архитектур, а именно: MVC, MVP, MVVM, VIPER. Плюс также есть статья отдельно про Clean Swift (VIP).

Мы в Jivo сначала пользовались подобием MVP, но затем со временем (и по мере роста) нам начали открываться некоторые не очень комфортные особенности этой архитектуры для наших условий. Соответственно, была произведена попытка выбрать наиболее комфортную из других популярных, но везде встречались те или иные не очень приятные нюансы.

В итоге мы решили изобрести свой велосипед исследовать область архитектурного вопроса с нового ракурса, и в последствии пришли к паттерну, который получил наименование Round Table.

Однажды нам довелось столкнуться с задачей, в рамках которой понадобилось практически жонглировать переводами одной и той же по смыслу фразы, которая слегка видоизменялась в зависимости от контекста.

В результате удалось успешно решить эту задачу, и вдобавок вынести решение в Open Source.

Еще одна архитектура?

В последние годы заметно набрала обороты тема альтернативных архитектур для создания приложений под платформу iOS. На доске особого почета уже закрепились некоторые силачи, известные как MVP, MVVM, VIPER. А кроме них есть еще множество других, не столь распространенных.

Среди силачей, на мой взгляд, ни одна не является универсальной таблеткой для всех случаев:

• если нужно сделать пару маленьких экранов со статическим набором данных, то вводить полноценный VIPER довольно затратно;
• если не нравится реактивный подход, то MVVM с большой долей вероятности пройдет мимо;
• если столкнулся с проблемой Massive в большом проекте, то MVC наверняка уже не подходит.

Есть вариант использовать несколько архитектур, ибо многие позволяют в той или иной степени сочетать себя с другими, но это тоже не слишком удобно как минимум по трем причинам:

• по мере роста модуля может возникнуть надобность конвертировать его в другую архитектуру;
• при внесении изменений в модуль надо сначала сообразить, какая архитектура использована для него, и как именно надо вносить туда изменения;
• надобность добавлять код-адаптер, чтобы совместно использовать модули разных архитектур, ибо на пустом месте код вряд ли получится нативным одновременно для них обеих.

И вот, столкнувшись за последние четыре года со множеством проектов (несколько проектов из банковской сферы, несколько разнородных заказных, а также несколько своих собственных — как приложений, так и игровых), я сформировал для себя архитектурный подход, который теперь по возможности стараюсь использовать в любом проекте, который начинаю.

Пока что он меня не подводил. При этом не думаю, что я первопроходец: наверняка, многие уже используют аналогичный подход. Но поскольку в проектах, с которыми сталкивался лично я, с архитектурой было довольно непросто, я захотел поделиться своими соображениями.

- (NSString *)tableView:(nonnull UITableView *)tableView titleForDeleteConfirmationButtonForRowAtIndexPath:(nonnull NSIndexPath *)indexPath
{
    return @"Настроить";
}

- (NSArray<UITableViewRowAction *> *)tableView:(nonnull UITableView *)tableView editActionsForRowAtIndexPath:(nonnull NSIndexPath *)indexPath
{
    UITableViewRowAction *configureAction;
    configureAction = [UITableViewRowAction
                       rowActionWithStyle:UITableViewRowActionStyleNormal
                       title:@"Настроить"
                       handler:^(UITableViewRowAction * __nonnull action, NSIndexPath * __nonnull indexPath) {
                          // handle
                       }];
    
    return @[ configureAction ];
}