c # когда программировать на интерфейс?

Question

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

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

в идеале это означает, что каждый класс должен быть запрограммирован на интерфейс? когда не стоит использовать интерфейс?

Answer 1

Когда применяется принцип ЯГНИ.

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

Answer 2

ИМХО, вы должны стараться много использовать интерфейсы. Проще ошибиться, не используя интерфейс, чем используя его.

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

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

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

Answer 3

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

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

Answer 4

Используйте интерфейс, если вы ожидаете, что в одном и том же контексте потребуются различные варианты поведения. То есть если вашей системе нужен один класс клиента, который четко определен, вам, вероятно, не нужно использовать интерфейс ICustomer. Но если вы ожидаете, что класс будет соответствовать определенному поведению, то есть «объект может быть сохранен», который применяется к различным элементам объектов, тогда у вас должен быть класс, реализующий интерфейс ISavable.

Еще одна веская причина использовать интерфейс, если вы ожидаете разных реализаций одного типа объекта. Например, если ypu планирует SMS-шлюз, который будет направлять SMS через несколько различных сторонних сервисов, ваши классы, вероятно, должны реализовать общий интерфейс s.a. ISmsGatewayAdapter, поэтому ваша основная система не зависит от конкретной используемой вами реализации.

Это также приводит к «инъекции зависимостей», которая является техникой для дальнейшего разделения ваших классов и которая лучше всего реализуется с использованием интерфейсов

Answer 5

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

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

Answer 6

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

В противном случае применяется YAGNI.

Answer 7

Я предпочитаю как можно больше кодировать интерфейс. Мне это нравится, потому что я могу использовать такой инструмент, как StructureMap, чтобы сказать «эй ... принеси мне экземпляр IWidget», и он делает всю работу за меня. Но используя такой инструмент, я могу программно или с помощью конфигурации указать, какой экземпляр извлекается. Это означает, что во время тестирования я могу загрузить фиктивный объект, который соответствует интерфейсу, в моей среде разработки я могу загрузить специальный локальный кэш, когда я нахожусь в работе, я могу загрузить слой фермы кэширования и т. Д. Программирование с интерфейсом дает мне гораздо больше возможностей, чем не программирование с интерфейсом. Лучше иметь и не нужно, чем нужно и не иметь, здесь очень хорошо. И если вы занимаетесь программированием в режиме SOLID, то самый простой способ достижения многих из этих принципов начинается с программирования на интерфейсе.

Answer 8

Реальный вопрос: что делает ваш класс? Если вы пишете класс, который фактически реализует интерфейс где-то в .NET Framework, объявите его таковым! Почти все простые библиотечные классы будут соответствовать этому описанию.

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

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