Можно пойти ещё дальше. EditProfileFactory добавить поле типа ServiceFactory. ServiceFactory будет содержать метод getService() -> CurrentUserProviding. Внедрять ServiceFactory через конструктор EditProfileFactory. Таким образом можно будет тестировать EditProfileFactory. Минус — придется писать код для каждого сервиса. (Но мы ведь итак его пишем, когда регистрируем сервис).
Здравствуйте, в данный момент разрабатываю проект на viper. Если использовать generamba для создания модулей, то никаких особых проблем/замедлений/избытка кода это не влечет, а вот то, что все пишется в одном виде, очень сильно улучшает читаемость. К тому же, если мы пилим какой-нибудь сверх простой компонент (например обобщенный выбор из списка), то можно использовать обычный mvc. В связи с этим вопрос, а действительно ли нужно плодить новые архитектуры?
рекомендую посмотреть wwdc 2017 про swift 4. Одно из нововедений, которое будет внедрено в xcode 9, инкрементальная сборка. Суть проблемы, если сейчас вы изменили 1 файл, то у вас весь проект билдится заново. Особенно это доставляет, если вы разрабатывается на компе с hdd.
Вайпер в его «разбитости» упрощает тестирование кода. Так же, ваше желание маневрировать мне не сильно понятно, не могли бы вы описать подробнее, где вайпер мешает маневрировать?
Вайпер нужен для серьезных, долгосрочных проектов, в которых код покрывается юнит тестами. При его использовании, у разработчика появляется привычка писать тестируемый, разбитый на простые объекты код. Плюс, во время его использования, узнаешь, как же хранятся слои, лежащие ниже view слоя, и соответственно тебе не придется потом бегать как автор и спрашивать, а как же привязать жизнь этих объектов к контроллеру. Но имхо, все высказавшиеся правы в том, что времени на написание кода с этим паттернов уходит не мало. Но быстро, к сожалению, можно только говнокодить
Нет, а какие у вас проблемы возникли?
Мне не понравилось, что нужно прописывать путь к каждому файлу в run-script. А так, выглядит вполне годно.
Вайпер нужен для серьезных, долгосрочных проектов, в которых код покрывается юнит тестами. При его использовании, у разработчика появляется привычка писать тестируемый, разбитый на простые объекты код. Плюс, во время его использования, узнаешь, как же хранятся слои, лежащие ниже view слоя, и соответственно тебе не придется потом бегать как автор и спрашивать, а как же привязать жизнь этих объектов к контроллеру. Но имхо, все высказавшиеся правы в том, что времени на написание кода с этим паттернов уходит не мало. Но быстро, к сожалению, можно только говнокодить