Должны ли объекты модели иметь интерфейсы?

Question

Я создаю модель домена в моей системе. Должен ли я создавать интерфейсы для каждого объекта сущности при проектировании объектов моей модели? Люди говорили мне, что наш веб-уровень не должен заботиться о реализации сущности, и мы должны иметь возможность менять реализации, но я не уверен, что это когда-нибудь произойдет.

Например, если у нас есть класс Teacher, который поддерживает список студентов, метод getStudents может быть либо:

public List<Student> getStudents() {
      return this.students;
}

или это:

public List<Student> getStudents() { 
     return someExternalService.retrieveStudents();
}

Я понимаю это преимущество, но какова общая практика?

Answer 1

Если у вас нет веских оснований полагать, что вам нужно поменять модель, я бы об этом еще не беспокоился.Основано на принципе ЯГНИ ( Вам оно не понадобится )

Answer 2

Ни один из проектов, в которых я когда-либо видел или участвовал, не имел интерфейсов для сущностей домена.

Но в одном из моих проектов у меня был интерфейс NamedEntity:

public interface NamedEntity {
   int getId ();
   String getName ();
}

Все сущности домена реализовали этот интерфейс. Это дало мне возможность не создавать разные jsf-конвертеры для разных сущностей, а создать один конвертер, который использовал этот интерфейс вместо конкретных классов доменов.

Answer 3

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

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

Единственная причина, по которой объекты модели имеют интерфейсы, имеет смысл, если объект модели - это не просто объект типа бина, но объект, который также демонстрирует какое-то поведение.

Answer 4

Я не могу говорить об общей практике, но вряд ли речь идет о сокрытии реализации.

Речь идет о формализации интерфейса в качестве основы для документации и договоров.

Абстрагируя ваши модели в интерфейсы, вы создаете документацию для разработчиков сервисных клиентов. В зависимости от вашего стиля разработки, у вас может быть, а может и нет официальное описание вашей услуги (например, описание на основе WSDL). Интерфейсы могут удовлетворить эту потребность.

Answer 5

Извлечение интерфейса является одним из самых простых рефакторингов; в худшем случае это переименование класса -> метод перемещения. Попытка изменить свое мнение, когда вы найдете причину для этого, минимальна. Я всегда обнаруживал, что если решение легко изменить, оно еще больше укрепляет YAGNI и KISS. Противоположным аргументом является то, что изначально не требуется больших усилий для создания интерфейса, что является правдой, но обслуживание увеличивается со временем, если решение принимается много раз - часто не используется.

Answer 6

Мое общее мнение состоит в том, что я бы не создал бы один-к-одному набор интерфейсов для моделей домена, поскольку это не что иное, как дублирование структуры классов вашей модели домена. Ничего полезного не добавляет.

Два случая, о которых я могу сразу подумать, когда я рассмотрел бы вопрос о внедрении интерфейсов:

1. интерфейс описывает контракт / поведение некоторого набора классов в модели предметной области, где полезно моделировать это поведение независимо от классов, которые его реализуют
2. вам необходимо предоставить модель вашего домена внешним клиентам и скрыть от них подробности реализации

Другими словами, добавьте интерфейсы, если они помогают вам описать поведение или скрыть детали реализации от клиентов. Могут быть и другие причины, но на ум приходят две.