но не должен ему противоречить или изменять в такой степени
Это ты сам придумал: нет никакой степени. Плюс, ты также противоречишь сам себе: логика, которая ожидает, что птица будет лететь - поломается. Следовательно, нарушение LSP.
Есть два стула...: Структуры и Функции. Например, структуры: Window, Button, Theme — это просто данные, анемичная модель. Функции(глобальные методы): AddChildToParent(button, window), ApplyThemeTo(button, theme), AdjustLayout(window), Show(window) и т.п.
Имхо, вы сами ответили на свой вопрос.
У строителей, как правило, весь проект рассчитан на бумаге от начала до конца — откуда может появится страх, если ты знаешь все?
А вот программисты редко планируют, чаще «строят» на лету и не придерживаются каких либо принципов проектирования. Такой подход неизбежно приведет к каше в проекте, в котором тяжело отслеживать зависимости и тяжело понимать к чему приведет новое изменение — отсюда и страх — «а не пропустил ли я что-то».
Практически в каждой статье о шаблоне MVC в iOS делают одну и туже ошибку:
Изначально авторы приводят в качестве примера ТТУК и вместо того, чтобы исправить нарушение шаблона MVC, начинают искать решение в использование MVVM, VIPER и т.п.
В MVC, контроллер не должен знать детали реализации представление, а тут автор считает правильным конфигурировать ячейки таблицы именно в контроллере — из-за такой реализации контроллер и представлени жестко зависят друг от друга, и именно такой подход нарушает шаблон MVC и превращают контроллеры в ТТУК. Есть простое правило: представьте что вам нужно полностью заменить представление, при этом данные, бизнес логика, обработка действий пользователя остаются неизменными, например, вместо таблицы отображать данные в виде коллекции — если в этом случаи вам прийдется полностью менять контроллер — вы нарушили шаблон.
Также передача объекта user в представление userCell никак не нарушает шаблон — здесь user — это пассивная модель, которая отвечает за хранение данных и представление может и должно знать о ней. В MVC представление может зависить от пассивной модели, модель не может зависить от представления.
Нет не верно, смысл наследования в расширении функциональности.
Это ты сам придумал: нет никакой степени. Плюс, ты также противоречишь сам себе: логика, которая ожидает, что птица будет лететь - поломается. Следовательно, нарушение LSP.
LSP все еще нарушается: класс наследник не должен менять поведение базового класса.
Рассматриваете миграцию в Azure DevOps в будущем? Некоторые ваши шаги CI\CD там реализовать было бы проще.
Все очень просто. Во-первых, сеньоры не будут работать за еду. Во-вторых, за пару месяцев нельзя обучить новых программистов.
У строителей, как правило, весь проект рассчитан на бумаге от начала до конца — откуда может появится страх, если ты знаешь все?
А вот программисты редко планируют, чаще «строят» на лету и не придерживаются каких либо принципов проектирования. Такой подход неизбежно приведет к каше в проекте, в котором тяжело отслеживать зависимости и тяжело понимать к чему приведет новое изменение — отсюда и страх — «а не пропустил ли я что-то».
Изначально авторы приводят в качестве примера ТТУК и вместо того, чтобы исправить нарушение шаблона MVC, начинают искать решение в использование MVVM, VIPER и т.п.
В MVC, контроллер не должен знать детали реализации представление, а тут автор считает правильным конфигурировать ячейки таблицы именно в контроллере — из-за такой реализации контроллер и представлени жестко зависят друг от друга, и именно такой подход нарушает шаблон MVC и превращают контроллеры в ТТУК. Есть простое правило: представьте что вам нужно полностью заменить представление, при этом данные, бизнес логика, обработка действий пользователя остаются неизменными, например, вместо таблицы отображать данные в виде коллекции — если в этом случаи вам прийдется полностью менять контроллер — вы нарушили шаблон.
Также передача объекта user в представление userCell никак не нарушает шаблон — здесь user — это пассивная модель, которая отвечает за хранение данных и представление может и должно знать о ней. В MVC представление может зависить от пассивной модели, модель не может зависить от представления.