этого бота наверняка легко обмануть

может ты скидывал статью какую нибудь

или делал так: а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а

а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а. а а а а а а а аа а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а. а а а а а а а аа а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а. а а а а а а а аа а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а. а а а а а а а аа а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а. а а а а а а а аа а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а. а а а а а а а аа а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а. а а а а а а а аа а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а. а а а а а а а а

/pizdoboltop@TovarishchBot

Топ-10 болтунов:

1. Еxey Panteleev — 4585 слов.
2. Evgenii Elchev — 2726 слов.
3. Виталий Кудрин — 1713 слов.
4. Dmitry Skibin — 1387 слов.
5. Sasha Zolotarev — 1161 слово.
6. Yuri Ko — 992 слова.
7. Egor Tolstoy — 727 слов.
8. Vadim — 699 слов.
9. Мефодий Акатов — 672 слова.
10. Vyacheslav — 544 слова.

Чат: @tovbotn

изи

Структура VIPER

Если коротко у вас есть:
• Interactor, который содержит бизнес-логику, предусмотренную сценарием.
• Presenter, который содержит логику подготовки содержимого для отображения (полученного из Interactor) и для реакции на ввод данных пользователем (запрашивая новые данные от Interactor).
• View, которое отображает, что сообщил Presenter и передает ввод данных пользователем назад Presenter'у.

Первоначально мои коллеги именовали эту архитектуру как VIP архитектуру. В некотором смысле это нарушение прав, ведь это можно интерпретировать и как “Very Important Architecture”. Так как я не хочу, чтобы люди думали, что другие архитектурные решения не важны, я решил назвать ее VIPER и позже придумал, что E и R будут означать.

VIPER - это подход к архитектуре мобильных приложений (в частности - iOS), основанный на идеях Роберта Мартина, изложенных им в статье The Clean Architecture.


Основные задачи, которые помогает решить VIPER
• Обеспечение более полного покрытия тестами слоя Presentation, обычно включающего в себя Massive View Controllers.
• Разбитие самых крупных классов наших приложений на набор элементов с более-менее четко определенными границами ответственности.
Важно сразу же отметить, что VIPER - это ни в коем случае не набор строгих шаблонов и правил. Скорее это перечень рекомендаций, следуя которым можно построить гибкую и переиспользуемую архитектуру мобильного приложения. Мы, iOS команда Rambler&Co, адаптировали некоторые из каноничных принципов и сформировали определенный набор Best Practices для разработки тех или иных юзкейсов.
Первоначально VIPER может ломать сознание, особенно разработчикам без опыта командной работы над крупными проектами - отсутствует понимание необходимости независимости модулей приложения друг от друга и максимально возможного покрытия их тестами. Тем не менее, весь набор решений оправдывает себя даже для небольших приложений.

Основные достоинства и недостатки VIPER
Плюсы:
• Повышение тестируемости Presentation-слоя приложений.
• Полная независимость модулей друг от друга - это позволяет независимо их разрабатывать и переиспользовать как в одном приложении, так и в нескольких.
• Передача проекта другим разработчикам, либо внедрение нового, дается намного проще, так как общие подходы к архитектуре заренее определены.
Минусы:
• Резкое увеличение количества классов в проекте, сложности при создании нового модуля.
• Некоторые из принципов не ложатся напрямую на UIKit и подходы Apple.
• Отсутствие в открытом доступе набора конкретных рекомендаций, best practices и примеров сложных приложений.

Золотые слова

Небольшой ликбез по истории вопроса
• 08.2012 - Статья The Clean Architecture от Роберта Мартина.
• 12.2013 - Статья Introduction to VIPER от компании MutualMobile.
• 06.2014 - Выпуск objc.io #13 со статьей Architecting iOS Apps with VIPER от тех же MutualMobile.
• 07.2014 - Выпуск подкаста iPhreaks Show, в котором MutualMobile рассказывают о том, как появился VIPER, какие вопросы он решает, и как используется в их приложениях.
• 04.2015 - В рамках локального хакатона в Rambler&Co пишется первое приложение с использованием подходов VIPER.
• 12.2015 - У Rambler&Co больше десяти приложений на VIPER, как разрабатываемых в данный момент, так и выпущенных в AppStore.

Традиционным способом проектирования приложения под iOS является использование шаблона MVC (модель-представление-контроллер). Использование MVC для архитектуры приложения, может натолкнуть Вас на мысль, что каждый класс представляет собой модель, или представление, или контроллер. Поскольку значительная часть логики приложения не входит в модель или представление, она обычно оказывается в контроллере. Это приводит к проблеме, известной как Massive View Controllers, где контроллеры в конечном итоге делают слишком много. Если вся логика встроена в контроллер представления, это приводит к тестированию логики через UI, в свою очередь это является неправильным способом проектированиям логики. Также проще совмещать бизнес-логику и UI код в том же методе. Когда Вам будет нужно добавить новые функциональные возможности или исправить ошибку, то будет трудно определить, где внести изменение и при этом быть уверенным, что не будет непредсказуемых последствий в другом месте.

/pizdoboltop@TovarishchBot

Топ-10 болтунов:

1. Еxey Panteleev — 4585 слов.
2. Evgenii Elchev — 2726 слов.
3. Виталий Кудрин — 1713 слов.
4. Dmitry Skibin — 1387 слов.
5. Sasha Zolotarev — 1161 слово.
6. Egor Tolstoy — 1042 слова.
7. Yuri Ko — 992 слова.
8. Vadim — 927 слов.
9. Мефодий Акатов — 672 слова.
10. Vyacheslav — 544 слова.

Чат: @tovbotn

Использование всеми разработчиками команды одного code style не менее важно, чем единая точка зрения на архитектуру приложения и ответственности разных объектов. Наличие соглашений по работе с VIPER-стеком не исключение.

Общие правила для модуля
• Название модуля должно полностью отражать его назначение. Суффикс Module в название включать не следует. Пример: MessageFolder, PostList, CacheSettings.
• Все элементы модуля разбиты по подпапкам в рамках одной папки модуля. Пример: /NewPostUserStory
•     /NewPostModule
•         /Assembly
•         /Interactor
•         /Presenter
•         /Router
•         /View
•     /ChooseAvatarModule
•         /Assembly
•         /Interactor
•         /Presenter
•         /Router
•         /View
•
• Если по итогу написания модуля какие-то из его элементов остались неиспользованными, будь то классы, протоколы или методы, они удаляются.
• Все хелперы располагаются в подпапке своего слоя. Пример:
/Interactor /UserInputValidator UserInputValidator.h UserInputValidator.m /PlainObjectMapper PlainObjectMapper.h PlainObjectMapperImplementation.h PlainObjectMapperImplementation.m
- Все методы, с помощью которых слои общаются друг с другом, должны быть синхронными.

Пример:

```objc
@interface InteractorInput
- (void)obtainDataFromNetwork;
...

@interface InteractorOutput
- (void)didObtainDataFromNetwork:(NSArray *)data;
...
• Все методы протоколов, которыми закрыты элементы модуля, должны начинаться с глаголов - это помогает явно указать на то, что каждый из компонентов обладает поведением, а не состоянием.
• Методы, обозначающие начало действия, должны начинаться с глаголов, выражающих приказ или просьбу (глаголов повелительного наклонения).
• Методы, обозначающие завершение действия или процесса, констатацию факта должны начинаться с глагола прошедшего времени. Пример: - (void)obtainImageForPostId:(NSString *)postId;
• - (void)processUserInput:(NSString *)userInput;
• - (void)invalidateCurrentCache;
• В публичных интерфейсах всех классов и протоколов стараемся использовать forward-declaration, используя #import лишь при необходимости. Пример: #import <Foundation/Foundation.h>
•
• #import "PostListViewOutput.h"
• #import "PostListModuleInput.h"
• #import "PostListInteractorOutput.h"
•
• @protocol PostListViewInput;
• @protocol PostListRouterInput;
• @protocol PostListInteractorInput;
• @class PostListViewModelMapper;
•
• @interface PostListPresenter : NSObject <PostListModuleInput, PostListViewOutput, PostListInteractorOutput>
•
• @property (nonatomic, weak) id<PostListViewInput> view;
• @property (nonatomic, strong) id<PostListRouterInput> router;
• @property (nonatomic, strong) id<PostListInteractorInput> interactor;
• @property (nonatomic, strong) PostListViewModelMapper *postListViewModelMapper;
•
• @end

Начать новый проект, заложив в его основу VIPER-архитектуру, несложно. Но программисты в своей практике постоянно сталкиваются с задачей поддержки и развития приложений, чья кодовая база изначально разрабатывалась хаотично, без применения жестких правил проектирования. Часто бывает, что требований к первой версии проекта немного, они умещаются на одном тетрадном листе, и, соответственно, при разработке не уделяется должное внимание архитектуре приложения. А техническое задание ко второй версии получается не менее объемным, чем "Война и мир" Толстого, что, естественно, требует кардинально изменить подход к развитию проекта. Поэтому более сложной, но и более интересной задачей является миграция уже в какой-то степени готового iOS-приложения со слабым фундаментом на прочное основание гибкой и надежной архитектуры, которой является VIPER.

я все

/pizdoboltop@TovarishchBot

Топ-10 болтунов:

1. Еxey Panteleev — 4585 слов.
2. Evgenii Elchev — 2726 слов.
3. Виталий Кудрин — 1713 слов.
4. Egor Tolstoy — 1395 слов.
5. Dmitry Skibin — 1387 слов.
6. Sasha Zolotarev — 1161 слово.
7. Yuri Ko — 992 слова.
8. Vadim — 927 слов.
9. Мефодий Акатов — 672 слова.
10. Vyacheslav — 544 слова.

Чат: @tovbotn

читеры