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

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

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

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

или это:

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

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

11
interface java modeling oop

6 ответов

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

7

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

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

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

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

2

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

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

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

1

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

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

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

1

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

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

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

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

0

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

0