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

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

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

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

interface IStringCollection : ICollection<string>
{
}

Я говорю больше:

interface ISomethingProvider
{
  ISomething Provide(ISomethingOptions options);
}

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

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

Короче да, возможно над интерфейсом проекта. Учитывайте, когда ситуация действительно требует абстрактного базового класса и интерфейса, в то время как оба они схожи, существуют различные преимущества использования See Here. Обычно я заметил, что люди используют интерфейсы, когда они действительно должны использовать абстрактные базовые классы. С точки зрения OO интерфейсы должны использоваться для отображения общего поведения, которое может охватывать совершенно разные классы. Например, у вас может быть интерфейс IMove с помощью метода Move(). Теперь представьте, что у вас есть класс "Самолет", "Автомобиль", "Человек" и "Насекомое". Самолет и автомобиль могут унаследовать от абстрактного класса транспортного средства, но все же необходимо использовать IMove, а также Insect и Person, но все они будут реализовываться иначе. Я заметил, что я сам включаю людей, поэтому люди обычно используют интерфейсы для группировки классов, когда они действительно должны обрабатываться базовым классом.

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

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