Kodomo

Пользователь

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

Содержание

  1. Множественное наследование в питоне
    1. Зачем нужно множественное наследование
    2. Проблемы множественного наследования
    3. Алгоритм C3
    4. Вызов методов родителей
      1. Наивный подход
      2. super
      3. Атрибуты объектов
    5. Заключительное слово
    6. Ссылки

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

   1 class C(A, B):
   2     ...

Зачем нужно множественное наследование

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

На эту тему есть примерно два ответа.

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

Например, если бы мы в такой парадигме делали библиотеку для рисования интерфейсов, мы бы создали класс Shape (фигура), сделали бы Rectangle потомком этого класса, создали бы класс WithText (то, на чём есть текст), и создали бы класс Clickable (то, на что можно нажать). И из этих классов мы могли бы сделать традиционную прямоугольную кнопку: 

   1 class Shape(object):
   2     ...
   3 class Rectangle(Shape):
   4     ...
   5 class WithText(object):
   6     ...
   7 class Clickable(object):
   8     ...
   9 
  10 class Button(Clickable, Rectangle, WithText):
  11     ...

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

Второй ответ на вопрос, зачем нужно множественное наследование, примерно такой: если нам нужно сделать объект, который ведёт себя и как список, и как Tkinter.Canvas (например, поле для тетриса), то мы можем сделать новый класс, унаследовать его от одного из этих классов и добавить методов, чтобы он вёл себя дополнительно и как второй из этих классов, а можем просто унаследоваться сразу от обоих классов и добавить необходимого клея, чтобы состояние списка и состояние Canvas не рассинхронизировались. 

   1 class TetrisField(list, Tkinter.Canvas):
   2     ...

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

Если переформулировать, этот ответ можно сказать так: иногда множественное наследование – это просто удобно, чтобы сделать быстро и чтобы работало.

Проблемы множественного наследования

FIXME: если у обоих родителей есть одноимённые методы; как должен себя вести одноимённый метод ребёнка?

FIXME: если дед один, а родителей два (diamond diagram)

FIXME: разных сущностей – столько, сколько ребёнку кажется, что у него предков, или меньше (если кто-нибудь из них совпадает)? – это не риторический вопрос, оба ответа имеют смысл

Алгоритм C3

FIXME: линеаризация; какими свойствами хотелось бы, чтобы она обладала:

  • FIXME: консистентность
  • FIXME: сохранение локальных приоритетов
  • FIXME: монотонность

FIXME: описание

FIXME: пример: линеаризация diamond diagram

FIXME: пример: нелинеаризуемое дерево наследования

Вызов методов родителей

FIXME: проблема метода init

Наивный подход

FIXME: наивный способ вызова методов родителей; его проблемы

super

FIXME: super; почему super устроен именно так (в питоне линеаризация хранится в классе.mro; в объекте хранится class_; в mro нужно найти, от какого места идти дальше)

FIXME: проблемы смешения двух подходов; пример

FIXME: набор правил, как лучше всего поступать в общем случае

Атрибуты объектов

FIXME: "атрибуты родителей" vs. "методы родителей"; слоёный пирог; есть ли здесь проблемы?

Заключительное слово

FIXME: из всего этого кажется, что множественное наследование – это очень сложно, но на самом деле, для того, чтобы упереться в какую-нибудь из проблем, нужно приложить очень много усилий

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

Ссылки