Внедрение зависимости - кому принадлежит интерфейс? - PullRequest
5 голосов
/ 13 ноября 2009

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

Мое первое предположение состоит в том, что в AOP вы определяете библиотеку классов интерфейсов, разделенных именами по аспектам. например: company.aspect.logging.ILogger. Каждый модуль будет ссылаться на эту библиотеку и избегать того, чтобы какой-либо код, участвующий в реализации ILogger, также определял ILogger.

Лучшие практики?

Ответы [ 2 ]

1 голос
/ 14 ноября 2009

Определение библиотеки классов интерфейсов - хорошее начало. Это дает вам максимальную гибкость, поскольку вы можете варьировать всех потребителей и всех разработчиков полностью независимо друг от друга.

Недостатком этого подхода является то, что если ваши интерфейсы сами экспортируют другие интерфейсы, как это:

public interface IMyInterface
{
    IMyOtherInterface DoStuff();
}

вам может понадобиться написать много кода отображения, который может заполнять конкретные классы из интерфейсов (или вы можете использовать AutoMapper ).

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

0 голосов
/ 14 ноября 2009

Это зависит от назначения интерфейса:

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

Если целью интерфейса является определить стандартный протокол между одним поставщиком и набором альтернативных потребителей, то интерфейс принадлежит поставщику.

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

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

...