2011-09-29 3 views
4

Я недавно спросил об этом question, если я должен реализовать интерфейсы или абстрактные классы. Скоттм дал ответ, предлагая использовать оба варианта, но я все еще не уверен, почему я хотел бы это сделать. Есть ли польза в долгосрочной перспективе? Каковы преимущества этого?Преимущества использования абстрактного класса интерфейса?

Вот некоторые преимущества я думаю:

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

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

+0

Интересно, может ли .net 5.0 упростить ограничения, позволяя сопрягать интерфейс со статическим базовым классом и позволить интерфейсу объявлять реализации по умолчанию для методов и свойств с использованием статических членов класса. Я бы не подумал, что с этим приходится сталкиваться с серьезными техническими трудностями (каждый член интерфейса получит слот vtable, но некоторые будут указывать на статические методы), и он может как расширять интерфейсы, так и устранять необходимость «партнера», статические классы для предоставления таких вещей, как Enumerable .Empty (в отличие от IEnumerable .Empty) – supercat

ответ

6

Этот подход дает вам лучшее из обоих миров - гибкость интерфейсов с полезной опцией базового класса.

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

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

В .NET Framework есть несколько примеров как интерфейса, так и базового класса. Например, System.ComponentModel.IComponent и System.ComponentModel.Component

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

Да. Вы в основном описываете Interface Segregation Principle.

+0

+1 Вы говорите все это гораздо более лаконично, чем я сделал –

+0

Спасибо - меня часто задают этот вопрос в интервью! –

+0

Я обновил свой пост с чем-то, что я думаю, это преимущества, но я не уверен. – Xaisoft

1

Я предполагаю, что C# здесь, потому что другой вопрос был C# тег

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

Вы не можете поставить первый базовый класс там, потому что C# не все множественное наследование, поэтому вы никогда не сможете передать объект, который подклассы другого класса там.

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

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

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

Надеюсь, что это имеет смысл :)

+0

Это имеет смысл. Я мог бы только поместить 5 тегов, и это было подбрасывание между .NET или C# :) – Xaisoft

2

Интерфейс определит договор. Любой исполнитель (прямо или через абстрактный исполнитель) будет соответствовать этому контракту.

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

Смежные вопросы