Вы очень невнимательно читаете мои комментарии, похоже.
Хорошо, и что за responsibility?
В 3-й раз: управлять циклом жизни своего view и взаимодействовать с другими view controller'ами, управлять дочерними вью контроллерами — показывать и прятать (как это делает UITabBarController), реагировать на storyboard segue. Не находите, что это уже включает достаточно много ответственности и достаточно раздутый интерфейс (привет ISP)?
Т.е. вы сами себе немного противоречите? Вы говорите, что разбиение на слабо связанные элементы управляемые контроллерами и в то же время говорите, что разбиение на контроллеры избыточно и можно обходиться только UIView.
Нет, не противоречу. Я разделяю наследников UIViewController и контроллеры/презентеры MVC/MVP. Избыточно разделение на UIViewController наследников. Можно обходиться набором UIView, каждая управляется своим контроллером (не UIViewController).
И во многих случаях, я считаю, имеет смысл создавать контроллер, который будет управлять логикой UITextView, для того чтобы не выносить эту логику в общие контроллеры.
Но контроллер вовсе не обязательно должен наследоваться от UIViewController.
Этот механизм, на мой взгляд, и создан для обновления UIView в зависимости от состояния model при помощи controller'а и обратно.
Как бы да, так говорит нам Apple в документации на UIViewController. Но принцип единой ответственности говорит о другом. Кроме того в интерфейсе UIViewController нет ни намека на наличие у него модели.
Было бы интересно услышать аргументацию в поддержку этого мнения.
Аргументация — SRP. Более того, один экран может иметь несколько слабо связанных элементов, каждый такой элемент должен контролироваться отдельным контроллером (презентером). Это и есть путь избавления от massive view controller.
Разделение на childViewController делается не ради подгрузки, а ради гибкости, которую дает композиция.
Если нам не нужно реагировать на события жизненного цикла вью (viewWillAppear: и т.п.) или взаимодействия с другими вью конироллерами (willMoveToParentViewController: и т.п.), то можно обойтись набором UIView. Гибкость та же. Например UITextView — наследник UIView, а не UIViewController, хотя логики там будь здоров.
Однако с дочерними вью контроллерами удобнее работать в storyboard.
Главный недостаток storyboard — это невозможность внедрять внешние зависимости (что можно делать в nib/xib). Чтобы пробросить зависимость в сцену в глубине навигационного стека, приходится добавлять свойство в промежуточные view controller'ы, что нарушает принципы SOLID и делает код очень негибким. Другой подход — повсеместное использование синглтонов, что делает код не тестируемым.
UIViewController — это такой же объект как и все остальные, и что у него должна быть только одна ответственность — связывать model и view.
Однако, если мы посмотрим на интерфейс класса UIViewController, мы увидим, что Apple уже наделила его ответственностью — управлять циклом жизни своего view и взаимодействовать с другими view controller'ами.
Добавлять в него ответственность связывания model с view считаю в корне не правильным (несмотря на то, что пишет Apple в гайдлайнах). Потому эту ответственность нужно выносить в отдельный класс — presenter (или controller). В случае с MVVM эта ответственность лежит на data binding механизме.
Делить один экран на множество view controller'ов в большенстве случаев избыточно, так как нам не всегда нужна ленивая подгрузка view и прочие фичи UIViewController. Потому можно обойтись обычными сабвью со своими presenter/contoller'ами.
«Стандартная модель» VIPER — это статейка от Mutual Mobile с не очень хорошим примером, который хипстеры начали пытаться копировать, как священное писание. Рамблер попытался таки натянуть эту сову на глобус реальности, но это все тот же шаблонный подход (в буквальном смысле ибо есть генерируемые шаблоны классов).
Проблемы VIPER:
во всех реализациях, что я видел, на каждый экран создается один presenter и один interactor. В случае достаточно сложного экрана получаем massive presenter и massive interactor (от чего вроде бы пытались уйти). Хотя Дядя Боб и Mutual Mobile говорили об interactor'е на отдельный юз кейс. Только недавно Рамблер начал понимать, что c этим нужно что-то делать.
отсутствие состояния и единого источника истины (текущего состояния того что мы видим на экране). Дядя Боб описывал Clean Architecture на примере веб приложения типа тонкий клиент, там это нормально, но iOS приложения — толстые клиенты, поэтому нельзя слепо копировать этот подход.
нечеткая ответственность presenter'а и interactor'а. Часто presenter просто пробрасывает вызовы между view и interactor не имея логики, что делает его избыточным.
смешанная ответственность UIViewController, который помимо управления жизненным циклом своего view берет на себя обязанности рендеринга.
И это только вершина айсберга под названием VIPER.
Да не паттерн это, а подход к архитектуре с разделением кода на слои. У меня стойкое чувство, что последователи VIPER не утруждают себя просмотром лекции дяди Боба на эту тему (статья менее выразительна, на мой взгляд и хуже описывает основной посыл).
В моем случае гуглились именно что правильные решения с учетом всех граничных условий. Я когда их находил, уже после отправки задания (пытался быть честным, да и интересно было самому решить), — сильно расстраивался, так как понимал, что рейт будет завален.
Отсеивать можно, но тут важно не перегнуть палку. Я проходил вроде бы 3 теста на Codility. Уровень сложности задач был от очень простых до реально олимпиадных, при чем время на олимпиадные было меньше, чем на простые. Однако даже для простых задач есть набор тестов, которые по сути должны являются требованиями, но вы о них ничего не знаете. Соответственно ваш код могу запустить, например, с массивом очень большой длины на которую вы не рассчитывали, а условие задачи об этом умалчивает, и вы получите очень низкий рейт. Некоторые даже давали второй шанс с указанием результатов, в котором был список тестов: зеленых и красных. Но в попытке пофиксить один тест можно с легкостью завалить два других (вы ведь не видите код теста, только его абстрактное название) и еще ухудшить рейт. На код обычно вообще не смотрят при этом, так как тест дает рекрутер (видимо даже не советуясь с нанимателем) и пропускает только основываясь на рейте.
Была ситуация почти как в 2. но с исходом как в 1. Только вместо тестового мне предоставили код какого-то проекта. Кандидат при этом хорошо знал основы языка (Objective-C) и платформы, поэтому решили взять, хоть и не без сомнений.
Еще одной причиной был обычный для IT дифицит кадров. настолько большой, что компании боятся отпускать более-менее вменяемых кандидатов. Если сегодня вы не берете кандидата «сходу» и предлагаете ему тестовое задание, то завтра он примет офер другой компании.
1) Codility — полный бред, даже хуже вопросов по алгоритмам у доски. Может там и можно создать свое уникальное задание, но те, что давали мне, были задачками далекими от реальных и представляли собой классические олимпиадные задачки. Все бы ничего, но в них очень много граничных условий, которые очень сложно продумать за отведенное время. В итоге получаешь очень низкий рейт из-за мелкой ошибки вроде (< вместо <=). Все задачи, что мне давали, гуглились. Это значит, что проходят эти задания не те, кто честно пытаются их решить, а обычные Stack Overflow Driven девелоперы или олимпиадники (которые часто не так хороши в разработке реальных проектов).
2) Довольно хороший подход из моего опыта как со стороны кандидата, так и со стороны собеседующего.
3) Тут уже зависит, есть ли подходящие задачи для такого аутсорса.
Автор начинает с белой дыры, а заканчивает отрицательной массой, хотя стоило бы сделать наоборот. Белая дыра — это экстремальная конфигурация все той же отрицательной массы.
Может. У него есть барабан с километровым кабелем, которым он подключается к сети. Это не шутка:
Das Fahrwerk wird elektrisch angetrieben: Der Bagger hat für seine Stromversorgung eine Kabeltrommel mit einem Kilometer Stromleitung an Bord, die unterwegs immer wieder an andere Einspeisepunkte angeschlossen wird.
Для взрослого человека рекомендуемая глубина продавливания при массаже сердца — не менее 5 см. При неглубоком естественном дыхании ход грудины даже меньше. Кроме того частота движений — минимум 100 в минуту против одного вдоха в 6 секунд при естественном дыхании.
Однако для детей этого оказывается недостаточно:
Children who receive compression-only CPR have the same outcomes as those having received no CPR.
возможно, из-за меньшего объема легких — меньшей эффективности дыхательной системы.
Посмотрите, как устроена подушка безопасности, для начала. В ней уже есть парочка здоровенных дырок, чтобы она могла быстро сдуться и погасить удар. Даже если бы сигарета могла прожечь подушку, на работу последней это особо не повлияло бы.
Кераторефрактометрия при выключенной аккомодации (с помощью атропина) покажет истинные параметры оптической системы глаза. У меня она показала отклонения -0,5..-1,0 и астигматизм -0,5..-0,75 (привожу разброс для обоих глаз). Но врач в Украине (в частной клинике) при этих показаниях все равно пытался лечить спазм аккомодации (который обычно проявляется только в детском/подростковом возрасте) ирифрином и зарядкой для глаз без заметных результатов. Я проводил неделю в отпуске за рулем, смартфоном не пользовался практически, и никакого улучшения за это время не заметил, что еще раз доказывает, что зарядкой/расслаблением это не лечится. В Германии мне сразу сказали, что у меня минус и нужны очки — свободен. Поначалу было немного обидно, но потом я понял, что в Украине пытаются делать видимость лечения за твои деньги (в частных клиниках), когда лечить нечего. Подобрав очки я наконец вспомнил, что такое по настоящему хорошее зрение! Это не идет ни в какое сравнение с результатами от зарядки.
К сожалению, корректировать менее 1 диоптрии лазером не имеет смысла на данный момент, на сколько я понимаю.
Как-то так. Рекомендую очень хорошее объяснение в этом ролике https://www.youtube.com/watch?v=ZuvK-od647c, особенно про неравенства Белла. Гораздо нагляднее и без дурацких абстракций, вроде коробочек с лампочками.
Ваш друг не может узнать, в какой момент у вас выпало 11 решек. Тут все несколько сложнее. У вас не одна монетка, а целый ящик. Допустим, они пронумерованы. В любой момент вы можете взять любую монетку, подбросить и получить результат — орел или решку. После этого монетка всегда будет выпадать с первоначальным результатом. Запутанность дает вам возможность быть уверенным в том, что если у вас монетка номер 42 выпала в решку, то у вашего друга монетка с тем же номером выпадет в орел. Но он может бросить ее и через секунду и через год. Если он бросит монетку номер 43, а вы ее еще не бросали, то ситуация ровно противоположная. И он будет знать, что если у него выпал орел, то у вас выпадет решка.
Т.е. нет смысла переставать бросать, так как ваш друг об этом не узнает, пока вы не сообщите ему об этом через обычный субсветовой канал связи (или при личной встрече через 50 лет).
В 3-й раз: управлять циклом жизни своего view и взаимодействовать с другими view controller'ами, управлять дочерними вью контроллерами — показывать и прятать (как это делает UITabBarController), реагировать на storyboard segue. Не находите, что это уже включает достаточно много ответственности и достаточно раздутый интерфейс (привет ISP)?
Нет, не противоречу. Я разделяю наследников UIViewController и контроллеры/презентеры MVC/MVP. Избыточно разделение на UIViewController наследников. Можно обходиться набором UIView, каждая управляется своим контроллером (не UIViewController).
Но контроллер вовсе не обязательно должен наследоваться от UIViewController.
Как бы да, так говорит нам Apple в документации на UIViewController. Но принцип единой ответственности говорит о другом. Кроме того в интерфейсе UIViewController нет ни намека на наличие у него модели.
Аргументация — SRP. Более того, один экран может иметь несколько слабо связанных элементов, каждый такой элемент должен контролироваться отдельным контроллером (презентером). Это и есть путь избавления от massive view controller.
Если нам не нужно реагировать на события жизненного цикла вью (viewWillAppear: и т.п.) или взаимодействия с другими вью конироллерами (willMoveToParentViewController: и т.п.), то можно обойтись набором UIView. Гибкость та же. Например UITextView — наследник UIView, а не UIViewController, хотя логики там будь здоров.
Однако с дочерними вью контроллерами удобнее работать в storyboard.
Однако, если мы посмотрим на интерфейс класса UIViewController, мы увидим, что Apple уже наделила его ответственностью — управлять циклом жизни своего view и взаимодействовать с другими view controller'ами.
Добавлять в него ответственность связывания model с view считаю в корне не правильным (несмотря на то, что пишет Apple в гайдлайнах). Потому эту ответственность нужно выносить в отдельный класс — presenter (или controller). В случае с MVVM эта ответственность лежит на data binding механизме.
Делить один экран на множество view controller'ов в большенстве случаев избыточно, так как нам не всегда нужна ленивая подгрузка view и прочие фичи UIViewController. Потому можно обойтись обычными сабвью со своими presenter/contoller'ами.
Проблемы VIPER:
И это только вершина айсберга под названием VIPER.
Да не паттерн это, а подход к архитектуре с разделением кода на слои. У меня стойкое чувство, что последователи VIPER не утруждают себя просмотром лекции дяди Боба на эту тему (статья менее выразительна, на мой взгляд и хуже описывает основной посыл).
Еще одной причиной был обычный для IT дифицит кадров. настолько большой, что компании боятся отпускать более-менее вменяемых кандидатов. Если сегодня вы не берете кандидата «сходу» и предлагаете ему тестовое задание, то завтра он примет офер другой компании.
2) Довольно хороший подход из моего опыта как со стороны кандидата, так и со стороны собеседующего.
3) Тут уже зависит, есть ли подходящие задачи для такого аутсорса.
Это он и есть, если имеется в виду Пузырь Алькубьерре. То есть нужна все та же отрицательная масса.
Die grössten Bagger der Welt
Bagger 288
Однако для детей этого оказывается недостаточно:
возможно, из-за меньшего объема легких — меньшей эффективности дыхательной системы.
К сожалению, корректировать менее 1 диоптрии лазером не имеет смысла на данный момент, на сколько я понимаю.
Т.е. нет смысла переставать бросать, так как ваш друг об этом не узнает, пока вы не сообщите ему об этом через обычный субсветовой канал связи (или при личной встрече через 50 лет).