Является ли использование индивидуальных интерфейсов с объектами домена хорошей или плохой практикой? Зачем?
В Java все находится в форме класса.
Если вы хотите использовать любой объект, тогда у вас есть две фазы:
- Объявить
- Инициализация
Пример:
- Объявление:
Object a; - Инициализация:
a=new Object();
То же самое для концепции массива
- Объявление:
Item i[]=new Item[5]; - Инициализация:
i[0]=new Item();
Если вы не дают секцию инициализации, тогда возникает NullpointerException.
4 ответа
Это плохая практика, как описано, но ...
Нет конкретной причины, по которой ваши интерфейсы должны отличаться от сущностей вашего домена; иногда это действительно правильное отображение. Но подозрительно, что это всегда так. Вызывает беспокойство вопрос о том, действительно ли интерфейсы были спроектированы, или они были просто брошены на место из-за нехватки времени / лени.
Чтобы использовать ваш пример, интерфейс IAccount, который вы описываете, выставляет геттеры и сеттеры объекта Account; кажется немного странным и маловероятным, что все, что использует Учетную запись, будет нуждаться в установке баланса в учетной записи, и что это подразумеваемое разрешение указывается на этом уровне интерфейса. Нет ли в вашей системе места, где вы хотите просто проверить, но не установить остаток на Счете?
Самая большая причина для того, чтобы всегда указывать доменные объекты как интерфейсы, а не как классы, заключается в том, чтобы дать вам некоторую свободу в реализации. В вашем примере у вас есть только один вид IAccount, поэтому он немного избыточен.
Но что, если у вас есть, например:
public class Account : IAccount { ... } // Usual account, persistent
public class MockAccount : IAccount { ... } // Test mock object
public class TransAccount : IAccount { ... } // Account, not persistent
public class SimAccount : IAccount { ... } // Account in a performance sim
и т. Д.?
Определяя доменные объекты как интерфейсы, вы можете заменить реализации, не нарушая определение вашего домена.
В общем, если мои классы не будут частью шаблона проектирования, такого как Стратегия или Посетитель, я не добавляю интерфейсы.
Добавление интерфейсов действительно полезно для шаблонов проектирования, таких как Стратегия и Visitor, но в этих случаях я не копирую методы получения и установки классов домена. Вместо этого я создаю интерфейсы, которые являются специфическими для интерфейсов шаблона проектирования, которые я создаю.
interface SomeStrategy {
void doSomething(StrategyData data);
}
interface StrategyData {
String getProperty1();
String getProperty2();
}
Это позволяет мне позволить классам домена реализовывать эти интерфейсы или использовать шаблон адаптера. Я считаю, что это гораздо более чистый подход, который просто создает интерфейсы ради него.
Дизайн всегда должен уменьшать неопределенность. Создание интерфейсов ради этого не уменьшает неопределенности, на самом деле это, вероятно, увеличивает путаницу, поскольку в этом нет никакого смысла.
Интерфейсы «один-к-одному» на объектах - это антипаттерн
Джеймс Грегори выразился лучше, чем я здесь .