.NET - Можете ли вы над интерфейсом, а когда не следует взаимодействовать

ISwissArmyKnife!

Проконсультируйтесь с этим:

http://thedailywtf.com/Articles/Classic-WTF-Implements-ISwissArmyKnife.aspx

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

1. вам нужно, чтобы члены команды договорились о том, кто что должен делать, прежде чем они начнут кодировать - интерфейс затем точно документирует границу
2. когда вам действительно нужен интерфейс для решения проблемы, поэтому как минимум две реализации, которые не расширяют друг друга
3. Вы ожидаете случай 2

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

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

Как и все остальное - используйте умеренно и там, где это необходимо. Задайте себе вопрос «Тебе это понадобится?».

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

Это касается не только .NET, та же проблема возникает в Java довольно часто.

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

Прагматический подход гласит: просто выполняйте самая простая вещь, которая могла бы сработать и не увлекайтесь архитектурной космонавтикой.

Короче говоря, да, проект можно перенастроить. Учтите, когда ситуация действительно требует абстрактного базового класса и интерфейса, хотя оба они похожи, использование обоих Глянь сюда дает явные преимущества. Обычно я замечал, что люди используют интерфейсы тогда, когда им действительно следует использовать абстрактные базовые классы. С точки зрения объектно-ориентированного подхода интерфейсы следует использовать для перечисления общего поведения, которое может охватывать самые разные классы. Например, у вас может быть интерфейс IMove с методом Move (). Теперь представьте, что у вас есть классы Airplane, Car, Person и Insect. Airplane и Car могут быть унаследованы от абстрактного класса Vehicle, но все же должны использовать IMove, как и Insect и Person, но все они будут реализовывать перемещение по-разному. Я заметил, в том числе и я, люди склонны использовать интерфейсы для «группировки» классов вместе, хотя на самом деле это должно выполняться базовым классом.

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

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

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

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

Всякий раз, когда я вижу или слышу, как кто-то это говорит

Interfaces describe a contract for behavior

Я знаю, что нашел человека, который не понимает интерфейсов.

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

Интерфейсы описывают контракт для интерфейс, отсюда и название. У них нет поведения.

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

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

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