С какими паттернами проектирования ты работал

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

Отличаете ли вы паттерн от его названия и видите ли их в том фреймворке, где работаете. В PHP почти все классические решения уже встроены в Laravel или Symfony, поэтому интервьюер слушает, узнаёте ли вы их в готовом коде, а не только в учебнике.

Как отвечать

Называйте паттерн вместе с задачей и с тем, где он у вас встречался.

• Внедрение зависимостей через конструктор и контейнер: основной способ сборки приложения, и он же заменяет одиночку, потому что контейнер умеет отдавать один и тот же экземпляр.
• Стратегия: несколько драйверов одного действия за общим интерфейсом, например способы оплаты или форматы выгрузки, выбор по настройке.
• Наблюдатель: события модели в Eloquent или диспетчер событий в Symfony, побочные действия вынесены из сервиса в слушателей.
• Декоратор и цепочка обработчиков: промежуточные слои по стандарту PSR-15, кэширующая обёртка поверх клиента внешнего сервиса.
• Адаптер: единый интерфейс поверх разных файловых хранилищ или платёжных шлюзов.
• Фабрика: сборка объектов в тестах и создание доменных объектов со сложной валидацией.

Полезно сказать пару слов про два подхода к данным: активная запись в Eloquent против отображения данных в Doctrine, и чем это оборачивается для тестов.

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

Считают фасад Laravel тем же фасадом, что в классической книге. Это статический прокси к контейнеру, а не упрощённый интерфейс поверх подсистемы, и путаница здесь сразу заметна тому, кто писал на фреймворке сам.

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

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