должен ли каждый параметр использовать интерфейс?

Question

Если у меня есть такой метод, как:

public void AddProduct(Product product)
{

}

Должен ли я, чтобы все мои классы реализовали интерфейс, чтобы я мог сделать:

public void AddProduct(IProduct product)
{

}

(где продукт - это сущность (отображается в таблицу БД)

Answer 1

Там никогда не бывает серебряной пули. Интерфейсы и базовые классы вместе могут покрывать почти все потребности, но интерфейсы никогда полностью не заменяют базовые классы и наоборот.

Потенциальный риск "чрезмерного взаимодействия" заключается в том, что интерфейсы трудно изменить в будущем, особенно когда они распространяются в большем количестве кода. Если IProduct требуется новое свойство, то добавление его в интерфейс может потребовать широкомасштабных изменений. Базовые классы (абстрактные или иные) могут исправить это, упрощая изменение базы без влияния на подклассы.

С другой стороны, .NET не допускает множественного наследования, поэтому базовая классификация также далека от серебряной пули.

---

Интересное примечание: у меня нет источника, доступного сразу, но один из отцов фреймворка (Kwalina или Abrams или их коллега) отмечает, что интерфейсы были представлены в .NET в основном как альтернатива множественному наследованию ; и тон звучал так: если .NET нужно переписать с нуля, он, вероятно, будет использовать множественное наследование.

Answer 2

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

Итак, я бы использовал интерфейс, только если передаваемый объект содержит поведение , которое должен использовать ваш объект. Это в основном так, что при тестировании вы можете переключить этот объект с помощью фиктивного, чтобы убедиться, что он работает правильно.

Поскольку POD не содержат поведения, я бы не стал взаимодействовать с ними. Это потому, что я не вижу никакой выгоды. Если типы данных или содержимое вашего POD изменятся, вы повсеместно будете менять, когда POD используется, независимо от того, было ли оно буферизовано интерфейсом или нет. И нет смысла издеваться над POD для тестирования, потому что макет выглядит так же, как реальная вещь.

Answer 3

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

Например, если у вас есть объект Customer со свойством LastName, которое вам просто нужно прочитать в вашем методе, вместо параметра Customer укажите строковый параметр с именем lastName и просто передайте в myCustomer.LastName.

Answer 4

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

Если вы просто используете Product в качестве POCO , то я бы не стал.

Answer 5

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

Пример, который вы привели, кажется разумным использованием интерфейса. Как и любое другое решение, которое вы принимаете при разработке своей программы, вы должны рассматривать каждую ситуацию индивидуально. Но просто прикрыть всё интерфейсами - это дорога к безумию.