В Symfony и во многих других объектно-ориентированных языках и фреймворках для работы с ними, как правило, используются интерфейсы для определения контрактов, которые должны быть реализованы классами. Использование интерфейсов помогает создать слабую связность и упрощает разработку, поддержку и масштабирование кода.
Абстрактный класс, с другой стороны, является классом, который не может быть инстанциирован напрямую и существует для предоставления базового функционала и структуры для его наследников. Он может содержать абстрактные методы, которые являются не реализованными методами, требующими реализации в наследуемых классах.
Таким образом, ответ на вопрос зависит от контекста и конкретных требований вашего проекта. В некоторых случаях интерфейс может быть полезен для определения контрактов и гарантий, которые должны быть реализованы всеми наследниками абстрактного класса. В таком случае, интерфейс дает вам возможность указать, какие методы должны быть реализованы и какой функционал должен быть предоставлен.
Однако иногда использование интерфейсов для абстрактных классов может быть излишним и привести к избыточности и увеличению сложности кода. Если у вас уже есть четкий контракт, определенный абстрактным классом, и вы уверены, что все наследники обязательно реализуют этот контракт, то использование интерфейса для него может быть излишним.
В итоге, для применения интерфейса к абстрактному классу в Symfony или в других ООП системах, вам следует внимательно анализировать требования вашего проекта и рассмотреть конкретные сценарии использования. Если интерфейс может дать дополнительные преимущества, такие как множественное наследование или явное указание контракта, он может быть полезен. В противном случае, использование интерфейса для абстрактного класса может быть лишним.