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

Question

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

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

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

или это:

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

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

Answer 1

Если у вас нет оснований думать, что вам нужно будет заменить модель, я бы не стал беспокоиться об этом. Основываясь на принципе YAGNI (You ain't gonna need it)

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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