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

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

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

Как с чем-либо еще - используют с модерированием и, где необходимо. Спросите себя, "Вы, испытывают необходимость в нем?".

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

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

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

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

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

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

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

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

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

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

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

ISwissArmyKnife!

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

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

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

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

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

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

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

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

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