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