Объекты модели должны иметь интерфейсы?
Я создаю модель предметной области в своей системе. При разработке моих объектов модели я должен сделать интерфейсы для каждого объекта объекта? Люди сказали мне, что наш ярус веб-узлов не должен заботиться о реализации объекта, и нам необходимо выгрузить реализации, но я не уверен, что это когда-либо происходило бы.
Например, если у нас есть класс Учителя, который ведет Список Студентов, getStudents метод мог или быть:
public List<Student> getStudents() {
return this.students;
}
или это:
public List<Student> getStudents() {
return someExternalService.retrieveStudents();
}
Я понимаю это преимущество, но какова общая практика?
5 ответов
Если у вас нет веских оснований полагать, что вам нужно поменять модель, я бы пока об этом не беспокоился. На основе принципа YAGNI ( Вам это не понадобится )
Я думаю, что существует важное различие между наличием интерфейса для службы для извлечения объекта и самим объектом модели.
Во время выполнения служба для загрузки объекта модели может отличаться в зависимости от того, откуда вы запрашиваете данные. Но формат и тип ожидаемого объекта данных не изменяются, независимо от того, как вы создаете этот объект. Следовательно, объектам модели, которые несут состояние, не потребуется интерфейс, но классам обслуживания для создания и загрузки этих объектов модели нужен интерфейс.
Единственная причина, по которой объекты модели имеют интерфейсы, имеет смысл, если объект модели является не просто объектом типа bean-компонента, но и объектом, который также демонстрирует какое-то поведение.
В целом я считаю, что я бы не создавал индивидуальный набор интерфейсов для моделей предметной области, поскольку это не делает ничего, кроме дублирования структуры классов вашей модели предметной области. Ничего полезного не добавляет.
Я могу сразу вспомнить два случая, когда я рассмотрел бы введение интерфейсов:
- интерфейс описывает контракт / поведение некоторого набора классов в модели предметной области, где полезно моделируйте это поведение независимо от классов, которые его реализуют
- , вам необходимо предоставить модель своей предметной области внешним клиентам и вы хотите скрыть от них детали реализации
Другими словами, добавьте интерфейсы, если они помогают вам описывать поведение или помогают скрыть детали реализации от клиентов. Могут быть и другие причины, но на ум приходят две.
Ни в одном из проектов, которые я когда-либо видел или в которых участвовал, не было интерфейсов для доменных сущностей.
Но в одном из моих проектов у меня был интерфейс NamedEntity:
public interface NamedEntity {
int getId ();
String getName ();
}
Все доменные сущности реализовали этот интерфейс. Это дало мне возможность не создавать различные конвертеры jsf для разных сущностей, а создать один конвертер, который использовал бы этот интерфейс вместо конкретных классов домена.
Я не могу говорить об общей практике, но вряд ли дело только в скрытии реализации.
Речь идет о формализации интерфейса как основы для документации и контрактов.
Абстрагируя свои модели в интерфейсы, вы создаете документацию для разработчиков клиентских служб. В зависимости от вашего стиля разработки, вы можете иметь или не иметь формальное описание вашей службы (например, описание на основе WSDL). Интерфейсы могут восполнить эту потребность.