О стрельбе по множественному наследованию

Прочтение статьи Ильи Труба "О проблемах множественного наследования" вызвало у меня желание испытать себя на поприще критика. Специфика статьи и значимость сделанных в ней выводов заставляют меня начать ее анализ в обратном порядке — со списка литературы.

[1] Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд. /Пер. с англ. — М.: "Издательства Бином", СПб: "Невский диалект", 1998
[2] Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. /Пер. с англ. — СПб: Питер, 2001
[3] Страуструп Б. Дизайн и эволюция C++: Пер. с англ. — М.: ДМК Пресс, 2000
[4] Страуструп Б. Язык программирования C++. Третье издание. /Пер. с англ. — СПб.; М.: «Невский диалект» — "Издательство БИНОМ", 1999
[5] Мейерс С. Эффективное использование C++. 50 рекомендаций по улучшению ваших программ и проектов: Пер. с англ. — М.: ДМК, 2000
[6] Мейерс С. Наиболее эффективное использование C++. 35 новых рекомендаций по улучшению ваших программ и проектов: Пер. с англ. — М.: ДМК Пресс, 2000
[7] Голуб А.И. C, C++. Правила программирования. М: Бином. 1996
[8] Роджерсон Д. Основы COM /Пер. с англ. — М.: Издательский отдел "Русская редакция" ТОО "Channel Trading Ltd.", 1997

Большинство книг, правда, вышли на русском языке недавно, но говорить о технике программирования на Cи++ без предварительного прочтения того, что ей посвящено, просто не имеет смысла. То, что написано в них про ООП, стало классикой программирования. А избирательный поиск материалов по множественному наследованию, поразил меня не только большим количеством деталей, но и тем, как учитывались разноречивые мнения при выборе окончательного способа реализации [3].

Вызывает также возражение мысль, что Java базируется на Cи++. Базирование предполагает наследование с расширением или заменой поведения. Java наследует, в основном, только синтаксис, а расширяется, прежде всего, за счет концепции интерфейсов. Во всем остальном — это обрубок (по отношению к Cи++), предназначенный для написания "чисто объектных программ" и пропагандируемый, в качестве отпрыска Cи++, в маркетинговых целях. Не хочу обидеть этим Java-программистов. Да, на этом языке можно и надо писать прекрасные программы, равно как и на многих других. Лично мне эпитеты, высказанные в адрес Cи++ ("раздутого монстра" по отношению к Java), нисколько не мешают использовать его.

Я согласен с тем, что множественное наследование таит немало "подводных камней" и непросто для реализации и понимания. Даже природа не смогла продумать этот вопрос так, чтобы получить идеальные результаты. Допустимо только парное наследование, возможно кровосмешение и порождение уродов, а поведение наследников столь непредсказуемо, что трудно понять: поддается оно законам дизъюнкции, импликации или является результатом работы генератора случайных чисел. Вместе с тем, следует отметить, что, несмотря на неполноценность, множественное наследование, кроме Cи++, реализовано еще в Eiffel и CLOS [5].

В рассмотренном примере вывод об импликации сделан на основании булевого значения результата, активизирующего или прекращающего дальнейшие вычисления. В других же случаях (когда нет возвращаемого значения) возможны и иные решения, например, суммирование всех вариантов поведения, формирование нового, уникального поведения, случайный выбор поведения и т.д. Например, компьютерные шахматные фигуры могут издавать победный возглас при взятии фигуры неприятеля. Тогда, по умолчанию, королева должна затрубить "по-слоновьему" или разразиться грохотом пушек «по-ладьиному». Из того, что "ферзь ходит как слон и ладья", совершенно не следует, что ферзь выглядит как слон и ладья. А программирование складывается не только из функциональной информативности, но и из информации о состояниях. Вполне возможно, что именно импликация встречается гораздо реже прочих вариантов. Нужны доказательства ее исключительности, которые, на мой взгляд, представить весьма трудно.

Поэтому я думаю, что принципы, положенные в основу множественного наследования Страуструпом [3], достаточно здравы. Они позволяют использовать как обратные древовидные структуры, опирающиеся на множественные базовые классы, так и ромбовидные схемы на основе виртуальных базовых классов. Явное переписывание виртуальных методов позволяет реализовать любую стратегию поведения без дополнительных правил по умолчанию и исключений из них. Кстати, описанию того, как формировались эти принципы, посвящена страница 21 главы 12 в работе [3]. На мой взгляд, там изложена информация, необходимая для полного понимания возможностей множественного наследования в Си++.

Страуструп [3] приводит ряд ситуаций, когда множественное наследование можно удачно применять:

• для объединения независимых или почти независимых иерархий;
• для композиции интерфейсов;
• для составления класса из интерфейса и реализации.

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

Первая ситуация достаточно часто встречается в такой известной программной архитектуре, как «модель — вид — контроллер» (она частично зафиксирована в образце Observer [2]). Построенный на основе множественного наследования класс обеспечивает в дальнейшем поддержку независимого доступа по двум различным интерфейсам, осуществляющим совместную обработку общих данных. Композиция интерфейса применяется в стандартной потоковой библиотеке Cи++ и базируется на ромбовидной схеме. Итак, схема ненадежна, но использоваться может!

Другим примером использования множественного наследования, объединяющим независимые интерфейсы и одновременно обеспечивающим составление класса из интерфейса и реализации, является один из способов создания компонентов COM, описанный Роджерсоном [8]. Этот метод, по моему мнению, не является единственным, но считается одним из самых простых и эффективных.

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

Возможно, отладка проводилась, но при трансляции фрагментов своего работоспособного псевдокода, выдержанного "в классических традициях объектно-ориентированного анализа и языка Си++", автор пользовался какой-то навороченной версией компилятора. В моем же непосредственном распоряжении оказался только Microsoft VC++ 6.0, поэтому пришлось изрядно попотеть, чтобы добиться выполнения программы. Вот полный текст того, что получилось в результате:

// Использование множественного
// наследования для создания ферзя
// из слона и ладьи

enum coord1 {a ,b ,c, d, e, f, g, h};
 // горизонталь
enum  color {black, white};
 // цвет фигуры

// Фигура — общий предок всех остальных
class figure {
protected:
   coord1 letter;    // координата a..h
   int    digit;    // координата 1..8
   color  fig_color; // цвет фигуры
public:
   //конструктор
   figure(coord1 x, int y, color z)  
      : letter(x), digit(y), fig_color(z)
   {}
   //чистая функция "ход"
   virtual bool step (coord1 new_letter,
 int new_digit)=0;
};
// Класс Ладья реализует
  функцию "ход"
class castle: public virtual
 figure {
public:
   castle(coord1 x, int y, color z):
 figure (x, y, z)
   {}
   bool step(coord1 new_letter,
 int new_digit) {
   if ( ((new_letter == letter)
 && (new_digit != digit))
   || ((new_letter != letter)
 && (new_digit == digit)))
   { letter = new_letter;
 digit  = new_digit;
   return true;
   }
   return false;}};
#include <math.h> 
// Класс Слон реализует свою функцию "ход"
class elephant: public virtual
 figure {
public:
   elephant(coord1 x, int y, color z):
 figure (x, y, z)
   {}
   bool step(coord1 new_letter,
 int new_digit) {
   if (abs((new_letter - letter)
 == abs(new_digit - digit)) 
   && (new_letter != letter)) {
   letter = new_letter; digit
 = new_digit;
   return true;
   }
   return false;}};

// Класс Ферзь - наследник
 Ладьи и Слона 
class queen: public elephant,
 public castle {
public:
   //конструктор
   queen(coord1 x, int y, color z)
   : castle (x, y, z), elephant
 (x, y, z), figure (x, y, z)
   {}
   
   bool step(coord1 new_letter,
 int new_digit) {
   return castle::step(new_letter,
 new_digit) 
      || elephant::step(new_letter,
 new_digit);
}};

#include <iostream>
using namespace std;

void main(){
   queen q(e, 5, white);
   cout << q.step(h, 8) << endl;
   cout << q.step(e, 8) << endl;
   cout << q.step(h, 8) << endl;
   cout << q.step(h, 5) << endl;
   cout << q.step(a, 8) << endl;
   cout << q.step(d, 8) << endl;
   cout << q.step(c, 5) << endl;
   cout << q.step(a, 1) << endl;
}

Неприятным и неожиданным моментом этой реализации является необходимость дополнительного вызова конструктора виртуального базового класса в списке инициализации конструктора ферзя, но и этот нюанс объяснен в советах Мейерса [5]. Там же рекомендуется избавляться от данных в виртуальных базовых классах, чего, к сожалению, нельзя сделать в этом примере, так как и ладья, и слон повторят наборы своих данных в ферзе.

Вряд ли имеет смысл приводить эти цитаты. Однако следует отметить, что использование множественного наследования с виртуальными базовыми классами ведет к дополнительному расходу ресурсов. Классы, построенные по ромбовидной схеме, имеют дополнительные внутренние указатели. Это вынужденная плата за универсальность, которую необходимо учитывать при формировании иерархии классов. По крайней мере, я бы воздержался в рассматриваемом примере от использования множественного наследования и продублировал бы в ферзе поведение ладьи и слона. Зачем умножать отношения между сущностями и попадать под бритву Оккама [5], если они не используются в дальнейшем? Ведь интерфейс остается таким же, каким он будет и при одинарном наследовании! При этом метод, описывающий ход ферзем можно дополнительно оптимизировать. Вот мой вариант кода:

// Использование одинарного
// наследования и своей функции для
 определения шага ферзя

enum coord1 {a ,b ,c, d, e, f, g, h};
enum  color {black, white};

// Фигура - общий предок всех остальных
// Определяет интерфейс
class figure {
protected:
   coord1 letter;	  // координата a..h
   int    digit;	    // координата 1..8
   color  fig_color;	//цвет фигуры
public:
   //конструктор
   figure(coord1 x, int y, color z): 
      letter(x), digit(y), fig_color(z)
      {}
   //чистая функция "ход"
   virtual bool step
   (coord1 new_letter, int new_digit)=0;
};

// Класс Ладья реализует
  свою функцию "ход"
class castle: public figure {
public:
   castle(coord1 x, int y,
 color z): figure (x, y, z)
   {}

   bool step(coord1 new_letter,
 int new_digit) {
   if ( ((new_letter == letter) 
&& (new_digit != digit)) 
   || ((new_letter != letter) 
&& (new_digit == digit)))
   {
      letter = new_letter; digit
  = new_digit;
      return true;
   }
   return false;
}};

#include <math.h> 
// Класс Слон реализует
 свою функцию "ход"
class elephant: public figure {
public:
   elephant(coord1 x, int y,
 color z): figure (x, y, z)
   {}

   bool step(coord1 new_letter,
 int new_digit) {
   if (abs((new_letter - letter)
 == abs(new_digit - digit)) 
      && (new_letter != letter)) 
   {
      letter = new_letter;
      digit = new_digit;
      return true;
   }
   return false;
}};

// Класс Ферзь реализует сам
// реализует свою функцию "ход"
class queen: public figure {
public:
   //конструктор
   queen(coord1 x, int y,
 color z): figure (x, y, z)
   {}

   bool step(coord1 new_letter,
 int new_digit) {
   if ( ((new_letter == letter)
 && (new_digit != digit)) 
      || ((new_letter != letter)
 && (new_digit == digit))
      || (abs((new_letter - letter)
 == abs(new_digit - digit)) 
      && (new_letter != letter)))
   {
   letter = new_letter; digit
 = new_digit;
   return true;    }
   return false;
}};

...

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

// Использование одинарного наследования, 
// и внешних общих функций
...
// Внешняя функция, реально
// выполняющая ход ладьей
bool is_castle_step(coord1
 &old_letter, int &old_digit, 
      coord1  new_letter,
 int  new_digit)
{ if ( ((new_letter == old_letter)
 && (new_digit != old_digit)) 
   || ((new_letter != old_letter)
 && (new_digit == old_digit)))
   {
   old_letter = new_letter;
 old_digit  = new_digit;
   return true;
   }
   return false;
}

// Класс Ладья использует
// внешнюю функцию "хода ладьей"
class castle: public figure {
public:
   castle(coord1 x, int y,
 color z): figure (x, y, z)
   {}

   bool step(coord1 new_letter,
 int new_digit) {
   return is_castle_step(letter,
 digit, new_letter, 
new_digit);
   }
};

#include <math.h> 

// Внешняя функция, реально
// выполняющая ход слоном
bool is_elephant_step(coord1
 &old_letter, int &old_digit, 
      coord1  new_letter,
 int  new_digit)
{ if (abs((new_letter - old_letter)
 == abs(new_digit - old_digit)) 
   && (new_letter != old_letter)) 
   {
   old_letter = new_letter;
 old_digit = new_digit;

   return true;
   }
   return false;
}

// Класс Слон использует внешнюю
// функцию "хода слоном"
class elephant: public figure 
{
public:
   elephant(coord1 x, int y,
 color z): figure (x, y, z)
   {}

   bool step(coord1 new_letter,
 int new_digit) {
   return is_elephant_step(letter,
 digit, new_letter, new_digit);
   }
};

// Класс Ферзь использует внешние
// функции "ход ладьей" и "ход слоном"
class queen: public figure
{
public:
   //конструктор
   queen(coord1 x, int y,
 color z): figure (x, y, z)
   {}

   bool step(coord1 new_letter,
 int new_digit) {
   return is_castle_step(letter,
 digit, new_letter,
new_digit)
      || is_elephant_step(letter, 
digit, new_letter, new_digit);
}};

...

Кроме того, я скептически отношусь к «наиболее удачным примерам эффективного применения» ООП как программированию увиденного. Это уже не программирование, а рисование. То, что объект, инкапсулирующий методы, более нагляден, тоже сомнительно. Реально проектируемые классы очень часто описывают такие абстракции, которые увидеть нельзя. Им нет аналогов в реальном мире. Об этом говорят и уже упомянутые образцы проектирования [2] и Буч [1]. Эволюционное развитие уже написанного кода, необходимое при разработке больших программ, часто требует применения таких приемов, о которых нельзя заранее точно сказать, к какому стилю программирования они принадлежат: процедурному или объектно-ориентированному. Одно из главных преимуществ ООП — не адекватное отображение объектов реального мира, а способность поддерживать эволюционное развитие программ за счет сочетания виртуализации и наследования. Правильное же использование внешних процедур только расширяет возможности разработчиков.