C# - Добавление систематически является интерфейсом хорошая практика?

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

Для модульного тестирования это либо интерфейсы повсюду, либо виртуальные методы повсюду.

Иногда скучаю по Java :)

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

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

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

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

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

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

На ум приходит agile-концепция: «либо добавляющая ценность, либо принимающая ценность».

Что произойдет, если вы их удалите? Если ничего, тогда ... зачем они там?

В качестве примечания. Интерфейсы чрезвычайно полезны для Rhino Mocks, внедрения зависимостей и так далее ...

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

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

Я обычно держу это «в курсе» какое-то время, независимо от того, есть ли у меня интерфейс, базовый класс или и то, и другое, и даже является ли базовый класс абстрактным (обычно это так). Я буду работать над проектом (обычно это решение Visual Studio, в котором содержится от 3 до 10 проектов) какое-то время (возможно, пару дней), прежде чем я проведу рефакторинг и / или попрошу второго мнения. После принятия окончательного решения и рефакторинга и тестирования кода я сообщаю коллегам-разработчикам, что он готов к использованию.

Полезно для тестов.

Метод может принимать параметр типа ISomething, и это может быть SqlSomething или XmlSomething, где ISomething - это интерфейс, а SqlSomething и XmlSomething - классы, реализующие интерфейс, в зависимости от того, выполняете ли вы тесты (вы передаете XmlSomething в этом случае) или запуск приложения (SqlSomething).

Кроме того, при создании универсального проекта, который может работать с любой базой данных, но без использования инструмента ORM, такого как LINQ (возможно, потому, что ядро ​​базы данных может не поддерживать LINQ to SQL), вы определяете интерфейсы с помощью методов, которые вы использовать в приложении. Позже разработчики реализуют интерфейсы для работы с базой данных, создадут класс MySQLProductRepository, класс PostgreSQLProductRepository, которые наследуют один и тот же интерфейс, но имеют разную функциональность.

В коде приложения любой метод принимает в качестве параметра объект репозитория типа IProductRepository, который может быть любым.

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

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

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