Блог

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

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

Краткие сведения:

• Вопрос 1. В контексте ООП с языком, который поддерживает только одиночное наследование, при правильном проектировании, каковы некоторые виды использования интерфейсов над абстрактным классом?
• Вопрос 2: В контексте DDD, если он спроектирован правильно, каковы возможности использования интерфейсов над абстрактным классом?

Примечание: я прочитал все перечисленные похожие вопросы, но, похоже, ни один из них не дал мне ответа. Если я пропустил один, пожалуйста, дайте мне знать.

Для вопроса 1: независимо от поддержки множественного наследования интерфейсы являются спецификациями контракта, абстрактные классы являются базовыми классами.

Интерфейсы предоставляют классу возможность указать набор возможностей (например, IDisposable, IEnumerable и т. Д.), И рекомендуется, Чтобы они подчинялись принципу разделения интерфейсов.

Абстрактные классы должны реализовывать концепцию, которая может быть расширена или которая может иметь разные реализации в зависимости от контекста (например, HttpContextBase, AbstractButton и т. Д.).

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

Что касается вопроса 2: в контексте интерфейсов DDD являются деталями реализации. Я осмелюсь сказать, что вы можете использовать DDD и не использовать интерфейсы или абстрактные классы или даже наследование. До тех пор, пока у вас четко определены ограниченные контексты, агрегаты, сущности и VOS.

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

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

Преимущество интерфейсов заключается именно в том, что нет множественного наследования. Используя интерфейс, вы можете разрешить таким классам, как Forms, UserControls, Components и т. Д., Участвовать во взаимодействиях, Которые в противном случае были бы затруднительными / невозможными.

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

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

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