.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
Я стараюсь не использовать слишком много интерфейсов для тестирования. Я бы предпочел сделать публичную приватную ценность и/или классы вскрытия и/или временные методы при построении и тестировании до тех пор, пока не нахожусь в точке, где я создал другие объекты и тесты, которые в конечном итоге будут выполнять то, что мне нужно. Составляет его боль в заднице, чтобы поднять ваши изменения таким образом, но ваши тесты расскажут вам, когда вы забыли что-то изменить.
Ответ 10
ISwissArmyKnife!
Проконсультируйтесь с этим:
http://thedailywtf.com/Articles/Classic-WTF-Implements-ISwissArmyKnife.aspx