Это хорошая идея или плохая идея создать интерфейс для объектов передачи данных? Предполагая, что объект обычно изменчив.
Хотя мой пример на 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;
}
}Конечно, это упрощенный пример, в реальной жизни может быть больше полей.
java
object-oriented-design
Архимед Траяно
источник
источник
Создание интерфейса - это нормально, но НЕ так, как работает ваш пример. Вы должны удалить сеттер из интерфейса, и все будет в порядке:
Это позволяет использовать много разных реализаций, например, имя можно получить из базы данных ... Сеттер должен находиться в другом интерфейсе.
источник
Интерфейсы определяют контракт между классами, реализующими интерфейсы, и их клиентами. Они используются в качестве механизма абстракции, так что клиенты могут манипулировать «вещами, имеющими заданное поведение».
Таким образом, общий ответ на вопрос "должен ли я создавать и использовать этот интерфейс?" Это: Да, если вы можете связать (единую) концепцию с семантической значимостью для ваших клиентов.
Например, Comparable - хороший интерфейс, потому что он объясняет, что вещи можно сравнивать благодаря одному из их методов, и как клиент я заинтересован в работе с сопоставимыми объектами (например, для их сортировки). Напротив , CoolStuff не является хорошим интерфейсом, если вы признаете, что классные объекты не имеют определенного поведения (на самом деле, вы можете представить себе программное обеспечение, в котором имеет смысл работать с классными объектами, потому что они имеют общее поведение, такое как beCool метод).
В вашем конкретном случае я считаю, что ваш интерфейс бесполезен. Кто будет его использовать, как и когда? Вы не можете создать интерфейс для каждого из изменяемых значений. Так что спросите себя, что является подходящим и интересным свойством за ваши методы.
Если вам нужно иметь дело с объектами, у которых все их изменяемые значения доступны через пару методов, взгляните на понятие Java bean-компонента и то, как вы можете заставить свои классы принять их соглашения.
источник
Как сказал Майкл, не добавляйте интерфейс, если в этом нет особой необходимости.
Тестирование является примером веской причины. Хотя я предпочитаю использовать реальных соавторов, если они являются просто «объектами значения», как вы их называете, для истинной изоляции модульного теста вам может понадобиться создать поддельный объект для тестирования, и в этом случае интерфейс весьма полезен.
источник
Если вы хотите, чтобы этот объект имел какие-то проверки полей в будущем, вы должны инкапсулировать их на ранних стадиях.
источник
«Интерфейс для объекта значения» - это то, что я использую для вызова метода доступа.
Я испытал различные политики относительно необходимости доступа. Некоторые люди рекомендуют, когда, насколько это возможно, другие запрещают уменьшать количество кода для записи.
Ниже перечислены некоторые рациональные ссылки для методов доступа (или прямого использования стоимости):
Я лично рекомендую сократить число методов доступа и использовать их, когда вы ожидаете, что установщик (setName) станет более чем простым влиянием позже.
источник
Этот тип объекта ценности довольно низкого уровня. Я бы посоветовал подтолкнуть его в одном из двух направлений: (1) сделать объект значения неизменным, то есть, как реальное значение , или (2) поднять изменчивость до бизнес-функции, ориентированной на домен более высокого уровня, что означает, что мы должны раскрыть интерфейсы с точки зрения предметно-ориентированных единиц функциональности.
источник