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

Мно́жественное насле́дование — свойство, поддерживаемое частью объектно-ориентированных языков программирования, когда класс может иметь более одного суперкласса (непосредственного класса-родителя), интерфейсы поддерживают множественное наследование во многих языках программирования. Эта концепция является расширением «простого (или одиночного) наследования» (англ. single inheritance), при котором класс может наследоваться только от одного суперкласса.

В список языков, поддерживающих множественное наследование, входят: Io, Eiffel, C++, Dylan, Python, некоторые реализации классов JavaScript (например, dojo.declare), Perl, Curl, Common Lisp (благодаря CLOS), OCaml, Tcl (благодаря Incremental Tcl), а также Object REXX (за счёт использования классов-примесей).

Обзор

Множественное наследование позволяет классу перенимать функциональность у множества других классов, как например, класс StudentMusician может наследовать от класса Person, класса Musician и класса Worker, что сокращённо можно написать:

StudentMusician : Person, Musician, Worker.

Неопределённость при множественном наследовании, как в примере выше, возникает если, к примеру, класс Musician наследует от классов Person и Worker, а класс Worker, в свою очередь, наследует от Person; подобная ситуация называется ромбовидным наследованием. Таким образом, у нас получаются следующие правила:

Worker          :  Person
Musician        :  Person, Worker
StudentMusician :  Person, Musician, Worker

Если компилятор просматривает класс StudentMusician, то ему необходимо знать, нужно ли объединять возможности классов или они должны быть раздельными. Например, логично будет присоединить «Age» (возраст) класса Person к классу StudentMusician. Возраст человека не меняется, если вы рассматриваете его как Person (человек), Worker (рабочий) или Musician (музыкант). Однако, будет довольно логичным отделить свойство «Name» (имя) в классах Person и Musician, если они используют сценический псевдоним, отличающийся от настоящего имени. Варианты объединения и разделения вполне корректны для каждого из собственных контекстов и только программист знает, какой вариант является правильным для проектируемого класса.

Языки обладают различными способами разрешения таких проблем вложенного наследования, а именно:

• Eiffel предоставляет программисту возможность явным образом объединить или разделить унаследованные элементы от суперклассов. Eiffel автоматически объединит элементы, если у них будет одинаковое имя и реализация. Автор класса имеет возможность переименовать наследуемые элементы для их разделения. Кроме того, Eiffel позволяет явным образом выполнять повторное наследование вида A: B, B.
• C++ требует, чтобы программист указал, элемент какого из родительских классов должен использоваться, то есть «Worker::Person.Age». C++ не поддерживает явно повторяемое наследование, так как отсутствует способ определить какой именно суперкласс следует использовать (смотри критику). C++, также, допускает создание единственного экземпляра множественного класса благодаря механизму виртуального наследования (например, «Worker::Person» и «Musician::Person» будут ссылаться на один и тот же объект).
• Perl использует список классов для наследования в указанном порядке. Компилятор использует первый метод, который он находит при глубинном поиске в списке суперклассов или использовании C3-линеаризации иерархии классов. Различные расширения обеспечивают альтернативные схемы композиции классов.
• Python (см. наследование и множественное наследование в Python) имеет синтаксическую поддержку для множественного наследования, а порядок базовых классов определяется алгоритмом C3-линеаризации.
• Common Lisp Object System предусматривает полный контроль методов комбинации со стороны программиста, а если этого не достаточно, то метаобъектный протокол (Metaobject Protocol) дает программисту возможность модифицировать наследование, динамическое управление, реализация класса и другие внутренние механизмы без опасения повлиять на стабильность системы.
• Logtalk поддерживает оба интерфейса и реализацию мультинаследования, предусматривая объявление метода алиасов, поддерживающего как переименование, так и доступ к методам, которые могут оказаться недоступными, благодаря механизму разрешения конфликтов.
• Curl допускает только такие классы, которые явным образом отмечены как доступные для повторного наследования. Доступные классы должны определять вторичный конструктор для каждого обычного конструктора класса. Сначала вызывается обычный конструктор, статус доступного класса инициализируется за счет конструктора подкласса, а вторичный конструктор вызывается для всех остальных подклассов.
• Ocaml выбирает последнее совпавшее определение в списке наследования классов для определения метода реализации, используемого в случае неопределенности. Для переопределения поведения по умолчанию нужно просто указать метод, вызываемый при определении предпочитаемого класса.
• Tcl допускает существование множества родительских классов — их последовательность влияет на разрешение имен членов класса.
• Delphi с версии 2007 позволяет частично реализовать множественное наследование с помощью помощников классов (Class Helpers).

Smalltalk, C#, Objective-C, Java, Nemerle и PHP не допускают множественного наследования, что позволяет избежать многих неопределенностей. Однако, они, кроме Smalltalk, позволяют классам реализовать множественные интерфейсы. Кроме того, PHP и Ruby позволяют эмулировать множественное наследование за счет использования примесей (traits в PHP и mixins в Ruby), которые, как и интерфейсы, полноценными классами не являются. Множественное наследование интерфейсов позволяет расширить ограниченные возможности.

Критика

Множественное наследование критикуется за следующие проблемы, возникающие в некоторых языках, в частности, C++:

• семантическая неопределённость часто совокупно представляется как Проблема ромба.
• отсутствует возможность непосредственного многократного наследования от одного класса.
• порядок наследования изменяет семантику класса. Конструктор дочернего класса вызывает конструкторы непосредственных родителей, а те, в свою очередь - конструктор прародителя. Однако прародительский объект имеется в единственном экземпляре и конструировать его дважды нельзя, поэтому сработает вызов конструктора прародителя только конструктором первого родительского класса в списке наследования.

Множественное наследование в языках с конструкторами в стиле C++/Java усиливает проблему наследования конструкторов и последовательностей конструкторов, таким образом создавая проблемы с поддержкой и расширяемостью в этих языках. Объекты в отношениях наследования со значительно отличающимися методами конструирования довольно трудны для реализации в рамках парадигмы последовательности конструкторов.

Тем не менее, существуют языки, обрабатывающие эти технические тонкости (например Eiffel).

Существует мнение, что множественное наследование — это неверная концепция, порождённая неверным анализом и проектированием. В частности, для приведённого выше примера справедлив следующий вариант проектирования. Класс Person включает в себя один и более объектов класса Profession. Классы Student и Musician наследуют от Profession. Таким образом, StudentMusician будет представлен объектом класса Person содержащим объекты класса Student и Musician. Формально множественное наследование можно перепроектировать путём введения класса, являющегося «метаклассом» классов, от которых должно происходить множественное наследование. В приведённом примере таким метаклассом является Profession — профессия.

См. также

• Наследование
• Виртуальное наследование
• Примесь
• C3-линеаризация
• Множественное наследование интерфейсов

Ссылки

• Статья Джонатана Лурье на веб-сайте Builder.Com, посвященная реализациям в .NET-языках  (англ.)
• Руководство по использованию наследования в языке Eiffel  (англ.)
• Обзор наследования в языке Ocaml  (англ.)
• Открытая помощь для студентов, увлекающихся компьютерным программированием  (англ.)

Литература

• Stroustrup, Bjarne (1999). Multiple Inheritance for C++. Proceedings of the Spring 1987 European Unix Users Group Conference.
• Object-Oriented Software Construction, Second Edition, by Bertrand Meyer, Prentice Hall, 1997, ISBN 0-13-629155-4
• Eddy Truyen, Wouter Joosen, Bo Nørregaard, Pierre Verbaeten. A Generalization and Solution to the Common Ancestor Dilemma Problem in Delegation-Based Object Systems (англ.) // Proceedings of the 2004 Dynamic Aspects Workshop. — 2004. — No. 103–119.