Должны ли мои объекты Doctrine реализовывать интерфейсы?

Question

Мне сказали, что я должен кодировать мои объекты POPO Doctrine для реализации интерфейса. Я понимаю, что лучше всего использовать код для интерфейсов.

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

<?php 
class User implements UserInterface() 
{ 
    function getName() { 
     return $this->name; 
    } 

    function setName($name) { 
     $this->name = $name; 
    } 

    function addPermission(Permission $permission) { 
     $this->permissions[] = $permission; 
    } 
} 

interface UserInterface() 
{ 
    function getName(); 

    function setName($name); 

    function addPermission(Permission $permission); 
} 

Answer 1

я ответить на этот вопрос в рамках только объекты базы данных.

Вообще говоря, сущности не должны реализовывать интерфейс. Но есть исключения.

1. При передаче объектов на сторонний код.
   Как и в случае с UserInterface, некоторый сторонний код ожидает, что он сможет собирать данные об определенном объекте. Имя пользователя и адрес электронной почты, как и в случае с Symfony.

2. При распространении кода в качестве стороннего участника.
   Примером может служить RoleInterface. Например, ваш пакет может управлять объектами FOSUserBundle, но конечным пользователям может не понравиться ваша реализация или даже не хотите, чтобы они хранились в базе данных. Использование интерфейса позволяет нам повторно реализовать существующий код, не нарушая его. (Ваш пакет должен проверять интерфейсы, а не классы).

3. Когда что-то может измениться в будущем.
   Жесткие объекты кодирования существенно связывают их с кодом. Вы упомянули доктрину, но что, если в будущем вы захотите мигрировать, чтобы продвинуться? Как и пункт 2 выше, интерфейсы облегчают переход.

4. Тестирование
   Гораздо проще создавать макетные объекты, когда требуется только реализация интерфейса.

5. Разработка команды
   Как пункт 4 выше. Класс может измениться во время его создания, что часто приводит к обновлению вызовов методов в вашем коде. Это приводит к проблемам при наличии нескольких разработчиков. Наличие общего интерфейса заставляет каждого разработчика следовать правилам, управляемым интерфейсом.