Считаешь ли паттерны проектирования нужными

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

Есть ли у вас своё мнение и опыт, или вы пересказываете каталог GoF. В Python вопрос с подвохом: половина классических паттернов здесь решается средствами языка, и интервьюер смотрит, понимаете ли вы это или тащите в питон архитектуру из Java.

Как отвечать

Нужны, но как общий словарь, а не как обязательный набор. Ценность паттерна в том, что имя экономит объяснение: сказали «стратегия», и коллега понял устройство без чтения кода.

Дальше конкретика по языку:

• Strategy это функция или любой вызываемый объект в аргументе, отдельная иерархия классов не нужна;
• Singleton почти не нужен: модуль импортируется один раз и сам работает общим состоянием, а метакласс ради синглтона усложняет код и мешает тестам;
• Decorator встроен в синтаксис, functools.wraps и contextlib закрывают большинство случаев;
• Iterator это протокол и генераторы;
• Factory часто вырождается в словарь или в classmethod.

Что остаётся живым и стоит назвать: Adapter на границе с внешними сервисами, Repository и Unit of Work вокруг базы, чтобы бизнес-логика не зависела от ORM, Observer в событийных системах, Command для очередей задач и внедрение зависимостей через параметры конструктора, что важнее всего для тестируемости.

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

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

Отвечают заученным списком достоинств: читаемость, расширяемость, меньше ошибок. Это пересказ предисловия учебника, а не ответ на вопрос про личное отношение, и следующий вопрос про свой опыт применения обычно добивает.

Второе: несут в Python абстрактные фабрики, интерфейс на каждый класс и геттеры с сеттерами. property существует ровно для того, чтобы не писать геттеры заранее, а утиная типизация и Protocol заменяют явные интерфейсы.

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