Абстрактный класс или интерфейс. Какой путь правильный? - PullRequest
8 голосов
/ 12 февраля 2012

Существует два способа выбора между абстрактным классом или интерфейсом. Решение Microsoft и решение Oracle:


Microsoft, руководство по проектированию:

Используйте абстрактные классы (MustInherit в Visual Basic) вместо интерфейсов для отделения контракта от реализаций.

http://msdn.microsoft.com/en-us/library/ms229013.aspx


Oracle, Учебные руководства по Java:

Если абстрактный класс содержит только объявления абстрактных методов, он должен быть объявлен как интерфейс.

http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html


У меня вопрос, какой путь правильный? Решение Microsoft или Oracle? Обратите внимание, что я думаю, что выбор между абстрактным классом или интерфейсом не должен зависеть от языка программирования (Java или C #).

Ответы [ 3 ]

10 голосов
/ 12 февраля 2012

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

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

Один из распространенных подходов, которые я встречал в ряде кодовых баз на нескольких языках, таков:

  • Определите интерфейс для указания контракта
  • Создайте абстрактный класс, реализующий контракт, чтобы обеспечить любую общую реализацию, полезную для всех потомков
  • Реализации контракта затем имеют возможность начать с базового класса длядля удобства или просто для реализации интерфейса, если им нужен полный контроль

Четвертый шаг, который часто встречается в мире .NET, - это предоставление функций расширения удобства, встроенных в интерфейс.

7 голосов
/ 12 февраля 2012

Это 2 утверждения для разных контекстов.

Указания Microsoft, на которые вы ссылаетесь, относятся к «Проектированию библиотек классов».И там указана причина предпочтения абстрактных классов: вы можете добавить функциональность, ничего не нарушая.

Для разделения и разделения слоев и других границ Microsoft также предоставляет интерфейсы.

1 голос
/ 12 февраля 2012

Интерфейс не несет никакой реализации - это контракт.Это позволяет полностью отделить.

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

Также следует учитывать, что многие языки, такие как C # (и языки .net, такие как VB.net и т. Д.), А также Java, не допускают множественного наследования, поэтому интерфейсы становятся способомпозволяя классу иметь много поведений.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...