Почему любой вид абстракции использует интерфейсы вместо абстрактных классов?

Question

Heyho,

У меня в голове какое-то время есть вопрос, который, надеюсь, кто-то из вас быстро решит:

Я большой поклонник MVC, ASP.Net Mvc в моем случае.

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

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

Например, весь шаблон репозитория может быть выполнен с абстрактным базовым классом, все еще обеспечивающим тестируемость и взаимозаменяемость, или я что-то упустил?

Пожалуйста, укажите на ту часть, где мой мозг отстает:)

Answer 1

Интерфейсы используются в учебных пособиях, блогах и других местах, потому что на этих авторов особенно влияет группа методологий, называемых «дизайн для тестируемости».

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

Answer 2

История

Я однажды посетил группу пользователей Java встреча, где Джеймс Гослинг (Ява изобретатель) был основным докладчиком. Во время незабываемой сессии вопросов и ответов, кто-то спросил его: «Если бы вы могли сделать Java снова, что бы вы изменить? "" Я бы пропустил занятия ", он ответил. После того, как смех утих, он объяснил, что настоящая проблема не классы как таковые, а скорее наследование реализации ( расширяет отношения). Интерфейс наследование отношения) предпочтительнее. Вы следует избегать реализации наследование по возможности.

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

P.S. Я думаю, что новый язык Go основан на интерфейсах, а не на наследовании (выглядит довольно интересно).

Answer 3

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

Answer 4

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

Answer 5

Читайте об интерфейсах, абстрактных классах, критических изменениях и MVC здесь: http://ayende.com/Blog/archive/2008/02/21/Re-Versioning-Issues-With-Abstract-Base-Classes-and-Interfaces.aspx.

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

Answer 6

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