Что такое анимичные модели?

Что проверяют

Знаете ли вы термин и умеете ли говорить про проектирование, а не только про интерфейс. Речь об анемичной модели: тип хранит поля и доступ к ним, а все правила лежат снаружи, в сервисах и менеджерах.

Как отвечать

Сформулируйте суть: модель без поведения. Структура с изменяемыми полями, рядом слой сервисов, который эти поля крутит. Формально объекты есть, объектной модели нет, и правила размазаны по вызывающим местам.

Чем это плохо в приложении: инвариант вида «заказ нельзя оплатить дважды» или «скидка не больше суммы» невозможно защитить, потому что любое место кода может присвоить поле. Проверки дублируются на экране, в координаторе и в слое сети, и рано или поздно расходятся.

Как лечат в Swift:

• закрывать запись через private(set), а изменения проводить методами самого типа;
• проверять данные в инициализаторе, включая отказной init?, чтобы невалидный объект нельзя было создать;
• заменять наборы булевых флагов на enum с ассоциированными значениями, чтобы недопустимые состояния просто не выражались;
• держать поведение в расширениях типа, а не в общем менеджере на весь модуль.

Обязательно назовите границу. Транспортный слой анемичен намеренно: типы под Codable, ответы сети и записи хранилища это переносчики данных, логики у них быть не должно. Антипаттерн начинается там, где такой тип объявляют доменной моделью и тащат через всё приложение.

Где спотыкаются

Слышат в вопросе «анимацию» и отвечают про плавность интерфейса и слои. Термин про анемичность, обескровленность модели, и созвучие здесь ловушка: стоит переспросить формулировку, а не угадывать.

Считают, что любая структура без методов это ошибка. Для отображения и передачи данных плоский тип уместен, вопрос только в том, кто отвечает за инварианты домена.

Переносят логику в общий сервис и называют это архитектурой. Класс, который знает про все сущности сразу и меняет их поля снаружи, это та же анемичная модель, просто с большим файлом рядом.