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

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

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

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

или это:

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

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

Ответ 1

Если у вас нет оснований думать, что вам нужно будет поменять модель, я бы не стал беспокоиться об этом. Основываясь на принципе YAGNI (Вам это не понадобится)

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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