Правило можно описать без способа хранения
В вымышленном квесте правильное решение даёт десять баллов, неправильное — ноль. Для этого правила нужны входные сведения о результате проверки и понятный выход — количество баллов. Название таблицы, адрес сервера и формат файла не помогают определить ответ. Поэтому расчёт удобно отделить от сохранения. Тогда две маленькие проверки подтверждают само правило: правильное решение даёт десять, неправильное ноль. Сбой внешнего сервиса не должен маскироваться под ошибку арифметики.
Граница задаётся необходимыми действиями
Часть приложения, которая организует прохождение квеста, может зависеть от небольшого интерфейса сохранения результата. Ей важно, что объект умеет принять идентификатор игрока и число баллов; конкретный способ записи остаётся внутри реализации. В Python такое требование можно описывать через Protocol. Структурная совместимость означает, что учитываются необходимые методы и их типы, а не только общее наследование. Это инструмент описания ожиданий, а не автоматическое доказательство правильного поведения объекта.
Подставная реализация проверяет взаимодействие
Для учебной проверки вместо настоящего хранилища можно использовать объект, который запоминает переданные ему значения в памяти. После прохождения квеста проверяют, какой идентификатор и сколько баллов были переданы. Так обнаруживается другая ошибка: расчёт верный, но в сохранение ушло старое значение. При этом объект в памяти не доказывает, что настоящая база доступна или запись переживёт перезапуск. Проверки правила, взаимодействия и реального хранения отвечают на разные вопросы.
Не превращайте разделение в лишнюю сложность
Если каждая простая операция окружена несколькими пустыми слоями, читать программу может стать труднее. Начинайте с конкретной причины разделения: внешняя зависимость мешает проверке, правило часто меняется или требуется другой способ хранения. Полезно назвать ответственность каждой части одним предложением. Расчёт определяет баллы, организатор передаёт результат, хранилище выполняет запись. Если предложение постоянно содержит и ещё, возможно, граница размыта. Ошибки сохранения также нужно обрабатывать явно: отсутствие записи не следует выдавать пользователю за успешное завершение всей операции.
Попробуйте на практике
Спроектируйте на бумаге три части вымышленного Python-квеста без подключения к настоящей базе.
- Запишите правило начисления: правильный результат — десять баллов, неправильный — ноль. Укажите вход и выход расчёта без упоминания файлов и серверов.
- Определите минимальные данные для сохранения: условный идентификатор игрока и число баллов. Опишите требуемое действие хранилища одной фразой.
- Придумайте реализацию для проверки, которая только запоминает переданную пару значений. Обозначьте, чего она не проверяет относительно настоящей базы.
- Разберите ошибку: расчёт вернул десять, а в сохранение передан ноль. Укажите, какая проверка взаимодействия её обнаружит.
- Добавьте сценарий отказа хранилища. Сформулируйте, почему успешный расчёт ещё не означает успешное сохранение и какое состояние должно оставаться явно незавершённым.
Как проверить результат. Правило начисления проверяется без внешнего сервиса. Отдельно проверяются переданные данные и работа настоящего хранилища, а успешное вычисление не подменяет успешную запись.
Частые вопросы
Обязательно ли использовать Protocol в любой небольшой программе?
Нет. Он полезен, когда явное описание требуемых операций облегчает понимание и проверку типов. Сама граница ответственностей важнее выбора одного конкретного инструмента.
Достаточно ли теста с объектом в памяти?
Для проверки переданных значений он удобен. Доступность, ошибки и особенности настоящего хранения требуют отдельных проверок с соответствующей реализацией.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.