Приведите пример инкапсуляции

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

Понимаете ли вы, зачем прячут внутреннее устройство, и умеете ли переносить это на свой уровень работы. Аналитику ООП нужно не для того, чтобы писать классы, а чтобы описывать модель предметной области и границы систем так, чтобы разработка не спорила с постановкой.

Как отвечать

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

Дальше давайте пример из модели, а не из учебника. Возьмите счёт: у него есть баланс, но в требованиях нет операции «установить баланс». Есть пополнение, списание и блокировка суммы, и каждая проверяет свои условия. Баланс становится следствием проводок, а не полем, которое кто угодно перезаписывает. Инвариант формулируется прямо в требовании: баланс меняется только проводкой и не уходит в минус сверх разрешённого лимита.

На уровне систем это тот же принцип: сервис владеет своими данными и отдаёт их через контракт, а соседняя система вызывает метод API, а не читает его таблицу напрямую. Тогда изменение схемы хранения не ломает половину ландшафта, и у данных есть один ответственный владелец.

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

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

Сводят инкапсуляцию к геттерам и сеттерам на каждое поле. Открытый сеттер возвращает тот же прямой доступ к состоянию, только через лишний метод: инвариант по-прежнему ничем не защищён.

Второе: путают инкапсуляцию с абстракцией. Абстракция про то, какие детали вообще попадут в модель, инкапсуляция про то, кто имеет право менять состояние. На собеседовании этот вопрос почти всегда задают следом.

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