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

Question

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

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

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

interface IStringCollection : ICollection<string>
{
}

Я говорю что-то вроде:

interface ISomethingProvider
{
  ISomething Provide(ISomethingOptions options);
}

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

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

PS - это не так много о том, как писать интерфейсы.

Answer 1

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

Answer 2

Короче говоря, да, это возможно через интерфейс проекта. Примите во внимание, что когда ситуация действительно требует абстрактного базового класса и интерфейса, хотя они оба похожи, использование обоих см. Здесь . Обычно я заметил, что люди используют интерфейсы, когда им действительно следует использовать абстрактные базовые классы. С точки зрения ОО интерфейсы должны использоваться для перечисления общего поведения, которое может охватывать совершенно разные классы. Например, у вас может быть интерфейс IMove с методом Move (). Теперь представьте, что у вас есть класс Самолет, Автомобиль, Человек и Насекомое. Самолет и Автомобиль могут наследовать от абстрактного класса Транспортного средства, но все еще должны использовать IMove, так же как и Насекомое и Человек, но все они будут реализовывать движение по-разному. Я заметил, что, в том числе и я, люди склонны использовать интерфейсы, чтобы «группировать» классы вместе, когда действительно это должно обрабатываться базовым классом.

Answer 3

Как и во всем остальном - используйте с модерацией и при необходимости. Спросите себя " Тебе это понадобится? ".

Answer 4

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

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

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

Answer 5

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

Интерфейсы описывают контракт для поведения

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

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

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

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

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

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

Answer 10

ISwissArmyKnife!

Обратитесь к этому:

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