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

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

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

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

Мой главный аргумент в том, что интерфейсы помогают вам сделать более тестируемый код. Если конструктор класса или метод имеет конкретный класс в качестве параметра, сложнее (особенно в C #, где нет бесплатных фреймворков имитирования невиртуальных методов конкретных классов) сделать тесты РЕАЛЬНЫМИ модульными тестами.

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

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

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

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

Это также приводит к '

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

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

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

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

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

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

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

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