Множественное наследование

В программном обеспечении иметь несколько родительских классов.

Множественное наследование — это особенность некоторых объектно-ориентированных языков программирования , в которых объект или класс может наследовать функции более чем от одного родительского объекта или родительского класса . Оно отличается от одиночного наследования, где объект или класс может наследовать только от одного конкретного объекта или класса.

Множественное наследование было спорным вопросом в течение многих лет, ^{[1] [2]} при этом оппоненты указывали на его повышенную сложность и двусмысленность в таких ситуациях, как «проблема ромба», где может быть неясно, к какому родительскому классу принадлежит конкретная функция. наследуется, если указанную функцию реализует более одного родительского класса. Эту проблему можно решить разными способами, в том числе с помощью виртуального наследования . ^[3] Для устранения двусмысленности также были предложены альтернативные методы композиции объектов, не основанные на наследовании, такие как миксины и черты .

Подробности

В объектно-ориентированном программировании (ООП) наследование описывает отношения между двумя классами, в которых один класс ( дочерний класс) является подклассом родительского класса . Дочерний элемент наследует методы и атрибуты родительского элемента, что позволяет использовать общие функции. Например, можно создать переменный класс Mammal с такими функциями, как поедание, размножение и т. д.; затем определите дочерний класс Cat , который наследует эти функции без необходимости их явного программирования, а также добавляет новые функции, такие как погоня за мышами .

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

Реализации

Языки, поддерживающие множественное наследование, включают: C++ , Common Lisp (через объектную систему Common Lisp (CLOS)), EuLisp (через объектную систему EuLisp TELOS), Curl , Dylan , Eiffel , Logtalk , Object REXX , Scala (с помощью классов- миксинов ). ), OCaml , Perl , POP-11 , Python , R , Raku и Tcl (встроено в версии 8.6 или через Incremental Tcl ( Incr Tcl ) в более ранних версиях ^{[4] [5]} ).

Среда выполнения IBM System Object Model (SOM) поддерживает множественное наследование, и любой язык программирования, предназначенный для SOM, может реализовать новые классы SOM, унаследованные от нескольких баз.

Некоторые объектно-ориентированные языки, такие как Swift , Java , Fortran начиная с версии 2003 года , C# и Ruby реализуют одиночное наследование , хотя протоколы или интерфейсы предоставляют некоторые функции настоящего множественного наследования.

PHP использует классы признаков для наследования конкретных реализаций методов. Ruby использует модули для наследования нескольких методов.

Проблема алмазов

Диаграмма наследования класса Diamond.

« Проблема алмаза » (иногда называемая «Смертельным алмазом смерти» ^[6] ) — это неоднозначность, возникающая, когда два класса B и C наследуются от A, а класс D наследуется как от B, так и от C. Если существует метод в A, который B и C переопределили , а D не переопределяет его, то какую версию метода наследует D: версию B или версию C?

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

Ее называют «проблемой ромба» из-за формы диаграммы наследования классов в этой ситуации. В этом случае класс A находится вверху, B и C по отдельности под ним, а D объединяет их внизу, образуя ромбовидную форму.

смягчение последствий

Языки по-разному решают проблемы повторного наследования.

• C# (начиная с C# 8.0) допускает реализацию метода интерфейса по умолчанию, в результате чего класс A, реализующий интерфейсы Iaи Ibаналогичные методы, имеющие реализации по умолчанию, имеет два «унаследованных» метода с одинаковой сигнатурой, вызывая проблему ромба. Это смягчается либо требованием Aреализации самого метода, что устраняет неоднозначность, либо принуждением вызывающего объекта сначала привести объект Aк соответствующему интерфейсу, чтобы использовать реализацию этого метода по умолчанию (например, ((Ia) aInstance).Method();).
• C++ по умолчанию следует каждому пути наследования отдельно, поэтому Dобъект фактически будет содержать два отдельных Aобъекта, и использование Aчленов должно быть правильно квалифицировано. Если наследование от Ato Bи наследование от Ato Cпомечены " virtual" (например, " class B : virtual public A"), C++ уделяет особое внимание созданию только одного Aобъекта, и использование Aчленов работает правильно. Если виртуальное и невиртуальное наследование смешаны, для каждого невиртуального наследования существует один виртуальный Aи невиртуальный путь наследования к . C++ требует явного указания, из какого родительского класса вызывается используемая функция, т.е. C++ не поддерживает явное повторное наследование, поскольку не было бы возможности определить, какой суперкласс использовать (т. е. класс появляется более одного раза в одном списке производных [класс Dog: public Animal, Animal]). C++ также позволяет создавать один экземпляр множественного класса с помощью механизма виртуального наследования (т. е . он будет ссылаться на один и тот же объект).AAWorker::Human.AgeWorker::HumanMusician::Human
• Common Lisp CLOS пытается обеспечить как разумное поведение по умолчанию, так и возможность его переопределить. По умолчанию, проще говоря, методы сортируются по D,B,C,A, когда B в определении класса пишется перед C. Выбирается метод с наиболее конкретными классами аргументов (D>(B,C)>A) ; затем в том порядке, в котором родительские классы названы в определении подкласса (B>C). Однако программист может обойти это, задав определенный порядок разрешения методов или указав правило комбинирования методов. Это называется комбинацией методов, которую можно полностью контролировать. MOP ( протокол метаобъектов ) также предоставляет средства для изменения наследования, динамической диспетчеризации , создания экземпляров классов и других внутренних механизмов, не влияя на стабильность системы.
• Curl позволяет повторно наследовать только те классы, которые явно помечены как общие . Общие классы должны определять вторичный конструктор для каждого обычного конструктора в классе. Обычный конструктор вызывается при первой инициализации состояния общего класса с помощью конструктора подкласса, а вторичный конструктор будет вызываться для всех остальных подклассов.
• В Eiffel функции предков выбираются явно с помощью директив select и rename. Это позволяет разделить функции базового класса между его потомками или предоставить каждому из них отдельную копию базового класса. Eiffel позволяет явно объединять или разделять функции, унаследованные от классов-предков. Eiffel автоматически объединит функции, если они имеют одинаковое имя и реализацию. У автора класса есть возможность переименовать унаследованные функции, чтобы разделить их. Множественное наследование — частое явление при разработке Эйфеля; Например, большинство эффективных классов в широко используемой библиотеке структур данных и алгоритмов EiffelBase имеют двух или более родителей. ^[7]
• Go предотвращает проблему ромба во время компиляции. Если структура Dвстраивает две структуры B, и Cобе имеют метод F(), удовлетворяя таким образом интерфейс A, компилятор будет жаловаться на «неоднозначный селектор» D.F(), если он вызывается или если экземпляр Dприсваивается переменной типа A. Bи Cметоды можно вызывать явно с помощью D.B.F()или D.C.F().
• Java 8 представляет методы по умолчанию для интерфейсов. Если A,B,Cэто интерфейсы, B,Cкаждый из них может предоставить различную реализацию абстрактного метода , Aвызывая проблему ромба. Либо класс Dдолжен переопределить метод (тело которого может просто перенаправить вызов одной из суперреализаций), либо неоднозначность будет отклонена как ошибка компиляции. ^[8] До Java 8 Java не подвергалась риску проблемы Diamond, поскольку она не поддерживала множественное наследование, а методы интерфейса по умолчанию были недоступны.
• JavaFX Script в версии 1.2 допускает множественное наследование посредством использования примесей . В случае конфликта компилятор запрещает прямое использование неоднозначной переменной или функции. Доступ к каждому унаследованному члену по-прежнему можно получить, приведя объект к интересующему миксину, например (individual as Person).printInfo();.
• Kotlin допускает множественное наследование интерфейсов, однако в сценарии проблемы Diamond дочерний класс должен переопределить метод, вызывающий конфликт наследования, и указать, какую реализацию родительского класса следует использовать. например super<ChosenParentInterface>.someMethod()
• Logtalk поддерживает множественное наследование как интерфейса, так и реализации, позволяя объявлять псевдонимы методов , которые обеспечивают как переименование, так и доступ к методам, которые были бы замаскированы механизмом разрешения конфликтов по умолчанию.
• В OCaml родительские классы указываются индивидуально в теле определения класса. Методы (и атрибуты) наследуются в том же порядке, причем каждый новый унаследованный метод переопределяет любые существующие методы. OCaml выбирает последнее соответствующее определение списка наследования классов, чтобы решить, какую реализацию метода использовать в случае неоднозначности. Чтобы переопределить поведение по умолчанию, нужно просто квалифицировать вызов метода с нужным определением класса.
• Perl использует список классов для наследования в виде упорядоченного списка. Компилятор использует первый найденный метод путем поиска в глубину списка суперклассов или использования линеаризации C3 иерархии классов. Различные расширения предоставляют альтернативные схемы композиции классов. Порядок наследования влияет на семантику класса. В приведенной выше двусмысленности класс Bи его предки будут проверяться перед классом Cи его предками, поэтому метод in Aбудет унаследован через B. Это общее с Io и Picolisp . В Perl это поведение можно переопределить с помощью того mroили иного модуля для использования линеаризации C3 или других алгоритмов. ^[9]
• Python имеет ту же структуру, что и Perl, но, в отличие от Perl, включает ее в синтаксис языка. Порядок наследования влияет на семантику класса. Python пришлось столкнуться с этой проблемой после появления классов нового стиля, все из которых имеют общего предка — object. Python создает список классов, используя алгоритм линеаризации C3 (или порядок разрешения методов (MRO)). Этот алгоритм накладывает два ограничения: дети предшествуют своим родителям, и если класс наследуется от нескольких классов, они сохраняются в порядке, указанном в кортеже базовых классов (однако в этом случае некоторые классы, расположенные выше в графе наследования, могут предшествовать классам, расположенным ниже в графе наследования). график ^[10] ). Таким образом, порядок разрешения метода: D, B, C, A. ^[11]
• Классы Ruby имеют только одного родителя, но могут также наследовать от нескольких модулей; Определения классов Ruby выполняются, и (пере)определение метода скрывает любое ранее существовавшее определение во время выполнения. В отсутствие метапрограммирования во время выполнения это имеет примерно ту же семантику, что и крайнее правое разрешение в глубину.
• Scala допускает множественное создание экземпляров типажей , что допускает множественное наследование путем добавления различия между иерархией классов и иерархией типажей. Класс может наследовать только один класс, но может смешивать любое количество признаков. Scala разрешает имена методов, используя поиск расширенных «признаков» справа в глубину, прежде чем исключать все, кроме последнего вхождения каждого модуля в результирующем списке. Итак, порядок разрешения: [ D, C, A, B, A], который уменьшается до [ D, C, B, A].
• Tcl допускает использование нескольких родительских классов; порядок спецификации в объявлении класса влияет на разрешение имен членов, использующих алгоритм линеаризации C3 . ^[12]

Языки, допускающие только одиночное наследование , где класс может быть производным только от одного базового класса, не имеют проблемы ромба. Причина этого в том, что такие языки имеют не более одной реализации любого метода на любом уровне цепочки наследования независимо от повторения или размещения методов. Обычно эти языки позволяют классам реализовывать несколько протоколов , называемых интерфейсами в Java. Эти протоколы определяют методы, но не предоставляют конкретных реализаций. Эта стратегия использовалась ActionScript , C# , D , Java , Nemerle , Object Pascal , Objective-C , Smalltalk , Swift и PHP . ^[13] Все эти языки позволяют классам реализовывать несколько протоколов.

Более того, Ada , C#, Java, Object Pascal, Objective-C, Swift и PHP допускают множественное наследование интерфейсов (называемых протоколами в Objective-C и Swift). Интерфейсы подобны абстрактным базовым классам, которые определяют сигнатуры методов без реализации какого-либо поведения. («Чистые» интерфейсы, такие как интерфейсы Java до версии 7, не допускают никакой реализации или данных экземпляра в интерфейсе.) Тем не менее, даже когда несколько интерфейсов объявляют одну и ту же сигнатуру метода, как только этот метод реализован (определен) в любом месте цепочки наследования он переопределяет любую реализацию этого метода в цепочке над ним (в его суперклассах). Следовательно, на любом уровне цепочки наследования может существовать не более одной реализации любого метода. Таким образом, реализация метода с одним наследованием не демонстрирует проблему ромба даже при множественном наследовании интерфейсов. С введением реализации по умолчанию для интерфейсов в Java 8 и C# 8 все еще возможно создать проблему ромба, хотя это будет проявляться только как ошибка времени компиляции.

Смотрите также

• Ориентированный граф
• Никсон Даймонд

Рекомендации

1. Каргилл, штат Калифорния (зима 1991 г.). «Противоречие: аргументы против множественного наследования в C++». Вычислительные системы . 4 (1): 69–82.
2. Уолдо, Джим (весна 1991 г.). «Противоречие: аргументы в пользу множественного наследования в C ++». Вычислительные системы . 4 (2): 157–171.
3. Шерли, Натанаэль; Дюкасс, Стефан; Ньерстраз, Оскар; Блэк, Эндрю. «Черты характера: составные единицы поведения» (PDF) . Веб.cecs.pdx.edu . Проверено 21 октября 2016 г.
4. "Инкр Tcl". блог.tcl.tk. _ Проверено 14 апреля 2020 г.
5. «Введение в язык программирования Tcl». www2.lib.uchicago.edu . Проверено 14 апреля 2020 г.
6. Мартин, Роберт С. (9 марта 1997 г.). «Java и C++: критическое сравнение» (PDF) . Objectmentor.com . Архивировано из оригинала (PDF) 24 октября 2005 г. Проверено 21 октября 2016 г.
7. «Стандарт ECMA-367». Ecma-international.org . Проверено 21 октября 2016 г.
8. «Состояние лямбды». Cr.openjdk.java.net . Проверено 21 октября 2016 г.
9. _ perldoc.perl.org . Проверено 21 октября 2016 г.
10. Аннотация. «Порядок разрешения методов Python 2.3». Python.org . Проверено 21 октября 2016 г.
11. «Объединение типов и классов в Python 2.2». Python.org . Проверено 21 октября 2016 г.
12. "Страница руководства класса" . Tcl.tk. _ 16 ноября 1999 г. Проверено 21 октября 2016 г.
13. «Интерфейсы объектов — Руководство» . PHP.net . 4 июля 2007 г. Проверено 21 октября 2016 г.

дальнейшее чтение

• Страуструп, Бьярн (1999). Множественное наследование в C++. Материалы конференции Европейской группы пользователей Unix весной 1987 г.
• Создание объектно-ориентированного программного обеспечения , второе издание, Бертран Мейер , Prentice Hall, 1997, ISBN 0-13-629155-4 
• Эдди Труен; Воутер Йосен; Бо Норрегаард; Пьер Вербатен (2004). «Обобщение и решение проблемы дилеммы общего предка в объектных системах, основанных на делегировании» (PDF) . Материалы семинара по динамическим аспектам 2004 г. (103–119).
• Ира Р. Форман; Скотт Дэнфорт (1999). Использование метаклассов в работе . ISBN 0-201-43305-2.

Внешние ссылки

• Учебник по использованию наследования в Eiffel
• Учебник по эффективному использованию множественного наследования в Python
• Обзор наследования в Ocaml