Должен ли я создавать интерфейсы для объектов передачи данных?

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

Хотя мой пример на Java, он должен быть применим к любому другому языку с похожими понятиями.

interface DataTransferObject  {
    String getName();
    void setName(String name);
}

class RealDataTransferObject  implements DataTransferObject {

    String name;
    String getName() {
        return name;
    } 
    void setName(String name) {
        this.name = name;
    }
}

Конечно, это упрощенный пример, в реальной жизни может быть больше полей.

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

Это, как говорится, иногда может быть веская причина. Но во всех случаях, которые я видел, эти интерфейсы были частичными, охватывающими только одно или несколько свойств, совместно используемых несколькими классами, которые я хотел использовать полиморфно, не давая им общего суперкласса. Типичные кандидаты - это Idсвойство для использования в каком-либо реестре или Nameсвойство для отображения пользователю. Но это может быть полезно в любом случае, когда вы хотите, чтобы некоторый код обрабатывал все, что имеет X - просто создайте XSourceинтерфейс, который содержит getX(и, только если требуется, setX) методы.

Но отдельный интерфейс для каждого модельного класса, содержащий все свойства? Я не могу представить себе вескую причину сделать это. Плохая причина - плохо спроектированная структура, которая требует этого; Entity EJB сделали именно это, если я правильно помню. К счастью, они были настолько плохи, что никогда не набирали обороты и устарели с EJB 3.0

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

Создание интерфейса - это нормально, но НЕ так, как работает ваш пример. Вы должны удалить сеттер из интерфейса, и все будет в порядке:

interface ValueObject {
  String getName();
};

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

Интерфейсы определяют контракт между классами, реализующими интерфейсы, и их клиентами. Они используются в качестве механизма абстракции, так что клиенты могут манипулировать «вещами, имеющими заданное поведение».

Таким образом, общий ответ на вопрос "должен ли я создавать и использовать этот интерфейс?" Это: Да, если вы можете связать (единую) концепцию с семантической значимостью для ваших клиентов.

Например, Comparable - хороший интерфейс, потому что он объясняет, что вещи можно сравнивать благодаря одному из их методов, и как клиент я заинтересован в работе с сопоставимыми объектами (например, для их сортировки). Напротив , CoolStuff не является хорошим интерфейсом, если вы признаете, что классные объекты не имеют определенного поведения (на самом деле, вы можете представить себе программное обеспечение, в котором имеет смысл работать с классными объектами, потому что они имеют общее поведение, такое как beCool метод).

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

Если вам нужно иметь дело с объектами, у которых все их изменяемые значения доступны через пару методов, взгляните на понятие Java bean-компонента и то, как вы можете заставить свои классы принять их соглашения.

Как сказал Майкл, не добавляйте интерфейс, если в этом нет особой необходимости.

Тестирование является примером веской причины. Хотя я предпочитаю использовать реальных соавторов, если они являются просто «объектами значения», как вы их называете, для истинной изоляции модульного теста вам может понадобиться создать поддельный объект для тестирования, и в этом случае интерфейс весьма полезен.

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

«Интерфейс для объекта значения» - это то, что я использую для вызова метода доступа.

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

Ниже перечислены некоторые рациональные ссылки для методов доступа (или прямого использования стоимости):

• Аксессоры позволяют позже изменить способ хранения значения
• Accessors позволяет добавлять журнал доступа, когда вы хотите отладить свое программное обеспечение (при добавлении вызова журнала одним методом вы фиксируете каждое изменение значения)
• Средства доступа более соответствуют объектному программированию, каждая переменная инкапсулируется методами
• Аксессоры уменьшают выразительность кода (больше SLOC для того же результата)
• Accessors занимает немного процессора

Я лично рекомендую сократить число методов доступа и использовать их, когда вы ожидаете, что установщик (setName) станет более чем простым влиянием позже.

Этот тип объекта ценности довольно низкого уровня. Я бы посоветовал подтолкнуть его в одном из двух направлений: (1) сделать объект значения неизменным, то есть, как реальное значение , или (2) поднять изменчивость до бизнес-функции, ориентированной на домен более высокого уровня, что означает, что мы должны раскрыть интерфейсы с точки зрения предметно-ориентированных единиц функциональности.