Ответ на »сообщение 4519« (Владимир Лось)
Такой вот маленький "безобидненький" вопросик:

Всем вам, конечно же, известно, что во многих языках существуют операции сдвигов

Ох уж эти сдвиги битов в неизвестном направлении!..

Была бы моя воля, запретил бы все эти сдвиги и оставил бы только умножение на 2^n, где n может быть как положительным, так и отрицательным.

Приведу реальный пример из жизни. Заголовок RTP пакета имеет следующий формат:

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |V=2|P|X|  CC  |M|    PT      |      sequence number        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          timestamp                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          synchronization source (SSRC) identifier            |
  +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  |            contributing source (CSRC) identifiers            |
  |                            ....                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Realtime Transport Protocol RFC 1889
http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc1889.html

Если datagram - это массив байтов представляющих собой полученный RTP-пакет, то как распарсить первый байт:
А) Прямой порядок битов

int  v =  datagram[0] & 3;
bool p = (datagram[0] & 4) != 0;
bool x = (datagram[0] & 8) != 0;
int cc = (datagram[0] >> 4) & 15;

Б) Обратный порядок битов

int cc = ( datagram[0] & 15);
bool x = ((datagram[0] >> 4) & 1) != 0;
bool p = ((datagram[0] >> 5) & 1) != 0;
int  v = ( datagram[0] >> 6) & 3;

Оказывается, правилен вариант (Б). Но объяснить это невозможно, поскольку согласно рисунку и обычной формуле:

b = b0*2^0 + b1*2^1 + b2*2^2 + b3*2^3 + b4*2^4 + b5*2^5 + b6*2^6 + b7*2^7;

двоичной системы исчисления, правильным должен быть вариант (А).

Спрашивается зачем использовать такое понятие как сдвиг если изначально неизвестно откуда и куда биты на какой-то машине нумеруются и где же у них лево и право?.. В то же самое время, умножение на 2^n - инвариантно относительно любой машины и не оперирует такими понятиями как "лево" и "право".

Ответ на »сообщение 4519« (Владимир Лось)
___________________________

Уважаемые коллеги!

Такой вот маленький "безобидненький" вопросик:

Всем вам, конечно же, известно, что во многих языках существуют операции сдвигов (арифметических и логических), производимых над целыми числами.
Арифметический сдвиг влево практически не отличим (по характеру воздействия на содержимое целой переменной) от логического.
Со сдвигом вправо есть два решения:
1. Как в си – результат зависит от "подтипа" целого (со знаком или без)
2. Как в Обероне – результат есть результат "соответствующей" операции (SAR, SHR)...

Вопрос заключается в анализе на большую "объектноориетнированность" каждого из этих решений... То есть "пляшем" от структуры объекта или – от семантики операций?

Т.е., имеется в виду, что в Си тип операции сдвига задается неявно (из контекста), а в Обероне явно - ASH, LSH?
AFAIK, исключение скрытых механизмов является одним из принципов Оберона, так что вопрос можно ставить значительно шире.

P.S. IMHO, интереснее вопрос о различии в семантике операции знакового целочисленного деления (DIV и MOD).

Уважаемые коллеги!

Такой вот маленький "безобидненький" вопросик:

Всем вам, конечно же, известно, что во многих языках существуют операции сдвигов (арифметических и логических), производимых над целыми числами.
Арифметический сдвиг влево практически не отличим (по характеру воздействия на содержимое целой переменной) от логического.
Со сдвигом вправо есть два решения:
1. Как в си – результат зависит от "подтипа" целого (со знаком или без)
2. Как в Обероне – результат есть результат "соответствующей" операции (SAR, SHR)...

Вопрос заключается в анализе на большую "объектноориетнированность" каждого из этих решений... То есть "пляшем" от структуры объекта или – от семантики операций?

Ответ на »сообщение 4515« (hugi)
___________________________
Возникают ли в Limbo проблемы, связанные с неоднозначным соответствием сигнатуры запрашиваемого метода сигнатурам методов, описанных в АТД?
Извините, hugi, я не понимаю смысла словосочетания "неоднозначным соответствием сигнатуры". Если сигнатура не совпадает (за исключением имени функции), то это – уже просто другой тип функции. Мы же ведь могли просто "немного по-другому" назвать саму функцию, имея в виду при этом схожую (или такую же точно) семантику (bigger, higher, upper, a_bit_more_left, ... ). В своём ответе я указал, что пока "согласование на месте" производится только в месте описания параметризируемой функции. В месте вызова такой "настройки-указания-уточнения" пока нет. Я списался с витануовой (конкретно - с Форситом). Таки их это заинтересовало, говорят будут посмотреть в эту сторону...

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

Как с этим бороться? А в случае с Интерфейсами ИМЯ функции говорит Вам, что эта функция делает.
НИ О ЧЁМ ОНО НЕ ГОВОРИТ! Это – всего лишь СОГЛАШЕНИЕ между теми, кто знает английский, или пишет латиницей по-русски в своих программах... :о)

И, как я уже говорил, если Класс реализует Интерфейс Сравнимый, это означает с вероятностью ~100% (если только это не чья-то злая шутка), что в нём заявлена функция, позвляющая сравнивать экземпляры данного класса между собой. А вот что означает сигнатура (Self : ThisType; x : SomeType) : Boolean -- трудно сказать: то ли сравнение, то ли проверку делимости, то ли ещё что нибудь -- не понятно... Ибо имя -- не что иное, как отражение семантики. В этом его ценность.
bigger, higher, upper, a_bit_more_right, ...  – имена разные, но семантика – абсолютна одна и та же:
return item1.any_int_field > item2.any_int_field;

Да я согласен (и уже кажется соглашался), что некая "переизбыточность" позволяет формализовать некие проектные решения на уровне совокупностей и наборов функций (интерфейсов). Но это ВСЕГО ЛИШЬ соглашение о добровольной поддержке – не более.
Речь шла о другом. В случае с Лимбо, вам не нужна такая избыточность, если, по контексту, вы можете выделить (затребовать) В ДАННОМ МЕСТЕ метод объекта, который будет обладать требуемой семантикой. Отпадает обязательность городить огород с формализацией реализации данным объектом (его классом) НЕКОЕГО интерфейса (в данном случае – Сравнимости).
Я считаю, что как раз Лимбо приближается именно ближе к реальной жизни. Потому, что "интерфейсы" – умозрительные построения. Знания о них возникают не "из воздуха", а по фактам и описаниям характера и способов взаимодействия между объектами на "точках соприкосновения". Объекты, сами по себе, безлики и не классифицируемы изначально. А вот в местах, где происходит "контакт", определяется вид и характер "взаимодействия", происходит "овеществление" "интерфейсов". Именно здесь и определяется, "конкретизируется" "природа" и правила взаимодействия. То есть смысл интерфейсов "взагали", как формализованных описаний в программах малоценен, без явной формализации "точек применения" этих интерфейсов. Сильнотипизированные языки, конечно, помогают выявить несоответствия в местах вызова, но само "понятийное поле" получается сильно перегруженным.
Но это – только мое личное мнение и взгляд. Сегодня. Пока так. Может быть завтра, под влиянием опыта, проекта, книги, размышлений после них, я изменю своё "миропонимание" об ООП. Ведь и такой взгляд у меня не всегда был... Как, например, и на вопросы многозадачности и синхронизации, до знакомства с Активным Обероном, Лимбо и Эйфелем... :о)

Здесь второй вопрос: "Не предусмотрено ли в Limbo каких-либо (пусть даже не 100%-ных) гарантий по семантике метода соответствующего заявленной сигнатуре (ведь по сигнатуре трудно судить о семантике)?".
Да, скорее всего, этого НИГДЕ не может быть предусмотрено... Если только вы не "встроите" в систему разработки некие зачатки ИИ... :о) Да и то, речь опять будет идти о какой-то узкой предметной области...

Буду благодарен, если Вы ответите...
"Всё, что могу..."(с)(генерал в "Горячем снеге")

..., ибо, как я уже сказал, эти вопросы меня очень интересуют.
Если бы вы знали, как они меня интересуют!!!... :о)
А ещё "страшнее" меня интересует, что бы это моих нынешних коллег по работе СИЛЬНО заинтересовало... :о))))

Ответ на »сообщение 4516« (Сергей Перовский)
___________________________


На вскидку: http://citeseer.ist.psu.edu/context/122919/0
На русском найти сложно.

Спасибо. На русский я и не рассчитывал.

Ответ на »сообщение 4514« (hugi)
___________________________
На вскидку: http://citeseer.ist.psu.edu/context/122919/0
На русском найти сложно.

Уважаемый Владимир Лось,
в своём сообщении »сообщение 4260« я задал Вам два вопроса, ответы на которые меня очень интересуют, и потому я был бы Вам признателен, если бы Вы на них ответили.
Для ясности, чтобы восстановить контекст, я процитирую своё сообщение. И напомню также, что речь шла о, так сказать, видах полиморфизма в языках с явной поддержкой Интерфейсов (например, Java) и в Limbo. Итак...

ВЫ: Есть и сопутствующие обстоятельства... Я о них уже упоминал. Я имею в виду желательность (а, скорее, даже – необходимость) введения синтаксиса "в месте вызова" такой полиморфной функции. Может быть ситуация, когда нужная функция в объекте есть (семантика), и сигнатура по аргументам та, что нужно, да вот беда, имя отличается. В этом случае желательно с помощью некоей синтаксической конструкции указать компилятору, что за функцию действительно надо иметь в виду.
Я: А я имел в виду несколько другое... Или Вы проигнорировали мой вопрос: "Проблем с несоответствием имён не возникает, а с неоднозначным соответствием заявленной сигнатуре (когда более одного метода удовлетворяют предъявляемым требованиям)?".

Вот здесь первый вопрос: "Возникают ли в Limbo проблемы, связанные с неоднозначным соответствием сигнатуры запрашиваемого метода сигнатурам методов, описанных в АТД?"

ВЫ: Дык у нас и в "обычных" ООП-языках никакой гарантии по семантике нет. Взять хотя бы знаменитый пример с перегрузкой операций. Обычно главным аргументом против такой широкой практики как раз и служит отсутствие чёткого понимания (из текста программы) что конкретно за операции (смысл) стоят за конкретным значком... Интерфейсы пока не описывают семантики... К сожалению... :о)
Я: Да, нет же! Я не то имел в виду! Я имел в виду, что в Вашем примере можно, насколько я понял, передать в функцию сортировки переменную типа, в котором будет объявлена функция, сигнатура которой совпадает с сигнатурой функции сравнения, но это будет другая функция, однако функция сортировки не будет возмущаться по этому поводу, т.к. сигнатуры совпадают. Это ведёт к снижению уровня безопасности (устойчивости) программы. Как с этим бороться? А в случае с Интерфейсами ИМЯ функции говорит Вам, что эта функция делает. И, как я уже говорил, если Класс реализует Интерфейс Сравнимый, это означает с вероятностью ~100% (если только это не чья-то злая шутка), что в нём заявлена функция, позвляющая сравнивать экземпляры данного класса между собой. А вот что означает сигнатура (Self : ThisType; x : SomeType) : Boolean -- трудно сказать: то ли сравнение, то ли проверку делимости, то ли ещё что нибудь -- не понятно... Ибо имя -- не что иное, как отражение семантики. В этом его ценность.

Здесь второй вопрос: "Не предусмотрено ли в Limbo каких-либо (пусть даже не 100%-ных) гарантий по семантике метода соответствующего заявленной сигнатуре (ведь по сигнатуре трудно судить о семантике)?".

Буду благодарен, если Вы ответите, ибо, как я уже сказал, эти вопросы меня очень интересуют.

Ответ на »сообщение 4463« (Сергей Перовский)
___________________________
За ООП теперь уже тоже вырос достаточно мощный математический аппарат объектного исчисления, позволяющий, по крайней мере, однозначно трактовать любые манипуляции с наследованием и полиморфизмом.
Не дадите ли хотя бы несколько ссылок на материалы по объектному исчислению? А то мои многочасовые поиски в Интернете потерпели полное фиаско.
Заранее благодарен.

Ответ на »сообщение 4297« (ASU)
___________________________

Да, с чего Вы взяли, что я отказываюсь от своих слов? Вы пишите (4288): «Тогда, могу предположить, используя сведения о Вашем подходе, описанном в сообщениях, адресованных мне, что вся ваша система описана в одном классе, который является "агрегатом ролей" (это по аналогии с Вашим HomoSapiens). Но мне почему-то кажется, что Вы, вопреки своим рассуждениям, сделали иначе». Покажите мне то сообщение, где говорится о системе в одном классе, который является «агрегатом ролей», я таких сведений Вам не давал... пока.

Да, Вы правы, я неточно выразился, написав "агрегат ролей", но аналогия "с Вашим Homo Sapiens" остаётся.

Да, какой-то объект может выступать в разных ролях, но сие не означает, что он агрегирует роли! Сам объект про роли, которые он исполняет, может ничего не знать.

Согласен. Но так дело обстоит только при Вашем подходе.

Роль – это поименованная совокупность интерфейсов, но роль – это не класс и не объект.

Всё зависит от Вас. Вполне можно описать роль как класс. Это один из подходов.

Несколько раз в разговоре с Вами я говорил о композиции (см. например, 4204): «Хм... сколько степеней свободы имеет палец? А рука? А все тело человека? Продолжать или уже понятно?.. Сколько музыкальных произведений существует? Много?! А нот всего семь... а параметра только три... Сколько действий может совершить человек? Много?! А если разложить на простые движения (которых всего-то два: поступательное и вращательное)... «Зачем делать сложным то, что проще простого?». Характеристики (свойства) – это проявления (вовне) композиций из очень малого количества исходных (внутренних) элементов. Можно перечислять композиции, а можно попробовать понять их основу и правила построения (создания)».

Если Вы рассматриваете человека как робота, который только и может, что двигаться вперёд-назад, вправо-влево, махать руками и качать головой, то Ваш подход вполне можно применять, хотя это и сулит большие трудности, связанные с описанием ролей (в данном случае лучше говорить о композиции высокоуровневого действия из нескольких элементарных). Пожалуй, для системы управления механическим манипулятором такой способ больше подошёл бы.
Теперь перейдём к нотам. Музыкальные произведения отличаются по длине (количеству нот). Для ограниченной длины количество комбинаций очень ограничено. Роли же (того же самого Человека) отличаются не количеством однородных действий, а набором действий разнородных. Роль Боксёр не зависит от того, сколько ударов исполняющий её Человек нанёс за поединок, она характеризуется совокупностью действий: наносить разные удары, уклоняться и т.д. Так что Ваш пример с нотами неверен (кроме того ноты -- это элементы внутреннего устройства музыкального произведения, а мы говорим о предоставляемой функциональности).
Вернёмся теперь к Человеку. Через какую базовую функциональность Вы представите роль Ученик? Ученик должен ходить в школу, делать уроки (интегралы, например, считать), читать книги и т.д. Было бы любопытно взглянуть, по какому базису Вы разложите эти действия? Неужели собираетесь написать ИИ?

Но Вы упорно игнорируете возможность комбинирования, считая, что таких «сложных» системах, как Человек, нужно «прописывать все элементарные операции»... по всей видимости предполагая, что этих элементарных операций очень много. Много комбинаций, но не операций.

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

Ответ на »сообщение 4297« (ASU)
___________________________

Вот так уж да уж... Не успел оглянуться, а количество сообщений в теме перевалило уже за 4,5 тысячи.
Посему спешу принести глубочайшие извинения за столь несвоевременный ответ. Но, вместе с тем, надеюсь, что Вы ещё просматриваете эту тему и это сообщение попадётся Вам на глаза.


Почему Вы решили, что пример Буча нечем опровергнуть? Давайте разбираться... Предположим, что у нас описан некий класс, который имеет характеристики (пусть для примера характеристик будет три и они будут целочисленные). Теперь создадим несколько экземпляров данного класса (то есть, объектов) и присвоим характеристикам некие значения. Что мы получили? Полигон для тренировок по произвольной классификации. Например, можно классифицировать объекты по следующим параметрам: те, у кого первая характеристика меньше 1000, и те, у которых данная характеристика больше или равна 1000. Или так: те, у кого (характеристика1 + характеристика2) div характеристика3 < 1000 и... прочие. Сколько подобных классификаций можно предложить? Бесконечно много. Согласны? Но! Мы можем так «классифицировать» объекты некоего ранее созданного класса. Если бы не было ранее созданного класса, то и объектов бы не было, а, следовательно, и не на чем было бы упражняться. Правильно?

Нет, не правильно. Ваше рассуждение выглядит несколько неуклюже: "Если бы не было класса, мы не могли бы классифицировать экземпляры этого класса". Неужели нельзя абстрагироваться от программирования как такового? Всё можно объяснить гораздо проще: у нас есть набор объектов, и нам нужно их классифицировать. Как это сделать? Есть два пути (или даже больше -- см. у того же Буча): 1) по наличию характеристик; 2) по значению характеристик. Несостоятельность второго Вы и пытались продемонстрировать. На самом же деле никто не запрещает Вам классифицировать объекты (в смысле абстракции, а не экземпляры классов) вторым путём. Другое дело, что в программировании первый является более предпочтительным по ряду причин, из которых первая -- резкое сокращение числа классов, т.к их экземпляры могут быть параметризованы конкретными значениями характеристик. Однако это вовсе не означает, что нельзя производить классификацию по значению характеристик.

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

Само собой, класс в ООП определяет наличие характеристик, но из этого никак не следует, что он не может определять значения характеристик. Вот, если мы реализуемый классом алгоритм будем считать характеристикой, что тогда получится. А получится, что мы будем иметь набор классов, в которых алгоритм реализован по разному (паттерн Strategy). К примеру, будет у нас вот такая характеристика -- наличие алгоритма обхода препятствий, а значение этой характеристики -- конкретная реализация алгоритма. Конечно, всё это довольно спорно, зависит от того, как на всё это посмотреть.

Но вот мы и подошли к «подмене понятий»... Давайте вспомним сообщение (4073), в котором я говорил: «В основе ООП не лежит решение частных задач, важнее получить семантически стройную иерархию классов. Об этом забыли... иерархии начали строить на потребу... Потому сегодня проводить межи и расставлять разделительные вешки между модульным программированием и ООП... пустая трата времени, IMHO. Но разговор о семантическом моделировании и принципах построения хороших классификаций... совсем другая тема.». Отметьте, что у меня речь, шла о наследовании, о построении иерархии классов. А вот Ваша реплика (4074): «Видимо Буча, так Вас рассмешившего, всё-таки невнимательно читали. Он  в своём "ОО Проектировании" наглядно показывает, что "хороших" классификаций не бывает»... Здесь Вы уже говорите не о классификации наследования, а о... классификации-группировке... С этого все и началось... Так кто же подменил понятия: я или Вы?

Ого! "Классификация наследования"... Про "наследование" слышал, про "иерархию наследования" слышал, про "классификацию" слышал, про "классификацию наследования" -- не слышал... Не дадите ли определения?
Ну, да ладно... Возможно, Вы правы, пример Буча использует классификацию по значению, а не наличию признаков. И, таким образом, этот пример имеет весьма отдалённое отношение к программированию (т.к. последний способ классификации (по значениям признаков) по крайней мере не очень желателен для применения). Вы в этом видите "подмену понятий"? Я попробую привести другой пример, показывающий зависимость классификации от цели исследователя (хотя и у Буча их полно). Возьмём, например, животных. Мы можем разделить их на группы (т.е. классифицировать) в зависимости от наличия позвоночника (Позвоночные - Беспозвоночные), если этот признак нам важен; в зависимости от наличия конечностей (СНогами - Безногие) и т.д. Вот так вот...
Но я продолжу размышление... В отличие от вышеизложенного подхода, мы можем, конечно, определить класс Животные и, устанавливая его атрибуты наличиеПозвоночника и наличиеКонечностей, получать разных животных. Так вот смотрите: с учётом только что сказанного, классификация из предыдущего абзаца строилась по наличию признака или по его значению? Я вот, например, затрудняюсь ответить. Для меня, например, вопросы классификации являются довольно туманными и неясными. Возможно, это объясняется отчасти тем, что эта тема связана со свойствами человеческого сознания, процессом познания, отчасти сложностью мира, в котором мы живём, отчасти дополнительными ограничениями, налагаемыми требованиями расширяемости, гибкости и повторного использования создаваемого ПО, и отчасти, пожалуй, недостатком знаний в этой области. Но тема, я думаю, всё-таки больше философская, чем программистская, хотя и имеет непосредственное воплощение в этом ремесле. Да к тому же лежит больше в области интуиции и в каких-то глубинных слоях сознания, а не в области "рацио". Если так, то, наверное, трудно осознать то, на чём зиждется твоё мышление.

Ну, что ж, лирическое отступление окончено, поговорим о "хороших классификациях". Беседа с одним преподавателем убедила меня, по крайней мере, в том, что установить степень "хорошести" классификации бывает очень затруднительно. Действительно, всякое ПО есть модель. Модель никогда не повторяет реальность в полном объёме, модель -- всегда приближение. Плюс, модель строится для решения какой-либо задачи. Если модель решает задачу с заданным приближением и в течение заданного интервала времени (можно ещё какие нибудь ограничения придумать) то она может быть признана удовлетворительной. Из этого следует, что модель напрямую зависит от задачи, которую требуется решить. Причём моделей может быть несколько. В некоторых заданных условиях одна модель может более эффективно решать задачу, чем другая. Также модели могут быть признаны равноценными (взять хотя бы машину Тьюринга, частично-рекурсивные функции и нормальные алгорифмы Маркова). В мире ПО дело обстоит ещё сложнее. Тесты определяющие пригодность (эффективность) модели (программы) часто недостаточно разработаны -- если вообще существуют. Всё определяется субъективным мнением пользователей, стоимостью рекламной кампании и т.д. Таким образом, возможно, и существует лучшая из имеющихся моделей, решающих поставленную задачу, хотя её выбор и сильно затруднён, но уж никак не лучшая из всех возможных -- прежде всего потому, что задачи разные, да и откуда нам знать, что придумают лет через сто?
Дальше...

О! Да!.. О наследовании Буч говорит много... слишком много... и смешно... Чтобы меня не обвиняли в голословности, приведу несколько цитат (все равно книгу уже нашел...).
Раздел 1.2. (стр. 33) «структура растений и животных»

Растение состоит из трех основных частей: корни, стебли и листья.

Раздел 2.2. (стр. 74-75) «примеры иерархии: множественное наследование»

Изучая предметную область, мы приходим к выводу, что различные группы культивируемых растений – цветы, фрукты и овощи, - имеют свои особые свойства, существенные для технологии их выращивания. Например, для цветов важно знать времена цветения и созревания семян. Аналогично, время сбора урожая важно для абстракций фруктов и овощей. Создадим два новых класса – цветы (Flower) и фрукты-овощи (FruitVegetable); оба они наследуют от класса Plant. Однако некоторые цветочные растения имеют плоды! Для этой абстракции придется создавать третий класс, FlowerFruitVegetable, который будет наследовать от классов Flower и FruitVegetablePlant.
Чтобы не было избыточности, в данном случае очень пригодится множественное наследование. ...
Мы намерено описали эти два класса [FlowerMixin и FruitVegetableMixin] без наследования. Они ни от кого не наследуют и специально предназначены для того, чтобы их подмешивали (откуда и имя Mixin) к другим классам

Что же получается... Если дерево состоит из частей, то почему растение, например, яблоня – есть яблоко? Почему в одном случае растение имеет корни, то в другом случае растение происходит от цветов, а не имеет цветы? И что такое цветок, который не растение и не часть его? И что произойдет с проектом, если «подмешивающих» (неприкаянных) классов будет очень много?..

Нет. Вы, видимо, недопоняли. Возможно, Буч не самый удачный пример привёл. Но уж не до такой же степени! Во-первых, да -- растение состоит из частей: корни, стебли, листья. Тут я не спорю. Смотрим дальше: различные группы культивируемых растений – цветы, фрукты и овощи, - имеют свои особые свойства, существенные для технологии их выращивания. Ключевые слова: "группы культивируемых растений - цветы, овощи, фрукты". Обратите внимание: цветы, овощи и фрукты -- не составные части, а обозначение ЦЕЛЫХ растений. И растение может предоставлять одновременно интерфейсы и цветов и овощей\фруктов. В Java или Delphi, например, это можно было бы реализовать с помощью определения соответствующих Интерфейсов. Но, поскольку Буч -- приверженец C++ (да и не было тогда ещё Java с Delphi), он использует технику множественного наследования с модификатором public -- стандартный для C++ метод. Теперь о том, почему появились примеси. Примеси появились из необходимости построить непересекающиеся интерфейсы (ну, плюс ещё для того, чтобы исключить проблемы, связанные с наличием общего предка). Получаем: Plant -- интерфейс растения, базовый класс; FlowerMixin -- интерфейс цветка (как самостоятельного растения) -[минус] интерфейс простого растения (это то общее, что есть у всех растений: папоротника, хвоща, розы, ели, яблони и т.д., то, что определяет Plant); FruitVegatableMixin -- интерфейс плодоносящего растения -[минус] интерфейс простого растения. По отдельности примеси не являются полноценными классами (в том плане, что они не могут быть инстанцированы, т.е. это абстрактные классы), но объединение интерфейсов классов Plant и FlowerMixin\FruitVegetableMixin или всех трёх позволяют получить полноценный интерфейс цветущего или плодоносящего (или и того и другого) растения. И в данном случае использование примесей как раз уменьшило число классов. Для пущей убедительности рассмотрим возможность агрегации. К примеру класс BananaPalm наследует от Plant и агрегирует экземпляр класса FruitVegetable. И что получается? На банановой пальме растёт один банан? Нееет! А если много бананов? Нееет, для нашей задачи это не нужно! Агрегация подошла бы, если бы Буч взялся подсчитывать количество яблок, которое упадёт на землю при высоте яблони 4м и силе ветра 5м/c. Вот такая вот информация к размышлению.

Но апофеозом является следующая фраза: «Часто агрегацию путают с множественным наследованием. Действительно, в С++ скрытое (защищенное или закрытое) наследование почти всегда можно заменить скрытой агрегацией экземпляра суперкласса. Решая, с чем вы имеете дело – с наследованием или агрегацией – будьте осторожны. Если вы не уверены, что налицо отношение общего и частого (is a), вместо вместо наследования лучше применять агрегацию или что-нибудь еще.» (стр. 133 Глава 3. Агрегация.)
Все... финал, Буч честно признался, что он не в состоянии привести критерии для того, чтобы разделить понятия наследования и агрегации. ... смешно и грустно... одновременно... Правда, таких перлов в книге более, чем... Посмотрите его описания «сложных систем», описания ключевых понятий ООП, подходы к разработке и организации работы команды...

И что? Вот же Вам признак: "...налицо отношение общего и частого (is a)...". Вы знаете другие? Приведите, пожалуйста, список. Механизм наследования ведь как раз и служит для выражения отношения "общее-частное", которое в свою очередь является основой для построения иерархии is-a. Более того, в данной конкретной цитате Буч не пытается РАЗДЕЛЯТЬ ПОНЯТИЯ. Понятия он определяет в другом месте. Здесь же Буч говорит о ПРИМЕНЕНИИ МЕХАНИЗМОВ наследования и агрегации (когда применять одно, а когда другое). Плюс ко всему, C++ накладывает свой отпечаток, ведь в нём "скрытое (защищенное или закрытое) наследование почти всегда можно заменить скрытой агрегацией экземпляра суперкласса". Только в этом случае наследование не используется как механизм порожедния подтипов. Иначе же вступает в силу признак "...налицо отношение общего и частого (is a)...". По поводу описания сложных систем могу заметить, что, насколько я знаю, не существует полного и точного определения этого понятия (как и в случае с понятием "информации"). По поводу ключевых понятий ООП то же самое: формального определения не встречал ни в одной книге. Если Вы знаете подобные определения сложных систем и ключевых понятий ООП, пожалуйста, приведите, любопытно было бы посмотреть на них. По поводу "подходов к разработке и организации работы команды" ничего не могу сказать, т.к. с этим конкретным аспектом программистской деятельности я на практике пока сталкивался крайне мало (по крайней мере, с организацией работы команды).