Здравствуйте, Alexey Chen, Вы писали:

AC>Указанный пример демонстрирует один из способов решения конкретной проблемы где можно использовать множественное наследование. Кроме догматических утверждений, что так плохо и примеров относящихся совершенно к другому, я аргументов против не увидел.

почему не увидели?

человек вам привел на конкретных примерах что ваша реализация плохо расширяется в случае изменения классов терминала или клавиатуры. по моему, вполне реальной.
а что это как не показатель не очень удачной архитектуры?

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

AC>Блин, меня жутко удивляет, когда на простой пример набрсываются "типа курутые мужики", что вот в больших системах..... Большие системы, между прочим, строятся из маленьких блоков. Люди знающие, что такое большая система, даже не подумают здесь приводить ее как аргумент. Это просто из другой оперы.

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

Здравствуйте, Mnmal, Вы писали:

M>человек вам привел на конкретных примерах что ваша реализация плохо расширяется в случае изменения классов терминала или клавиатуры. по моему, вполне реальной.
M>а что это как не показатель не очень удачной архитектуры?

Он привел это на _своих_ примерах применитльно к _своей_ задаче в _своем_ понимании этого вопроса. Разницу чувствуете?

Окей. Коли уж мы сцепились из за какого-то тривиального примера, поместим его в конкретную задачу и рассмотрим его корректность.

У меня есть программа которая работает с _терминалом_. Что такое терминал обьяснять надо? ANSI, VT102,...
У меня есть два класса которые реализуют чтение/запись с/в потока байтов и пользуясь термкапом превращают их в нажатия клавиш и символы на экране. Можно реализавать логику термкапав, как шаблонную фукцию, стратегтю параметризации, интерфейсы к имплементационным классом.... но обычно люди просто работают с термкапом.

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

Далее, чтобы отсечь обвинения в нарушении OCP и DIP, уточню, что классы реализующие работу с потоками реализуют интерфейсы полностью совпадающие с ними по публичным функциям, а код работающий с входом/выходом работает с этими интерфейсами.

Терминал это класс для обьектов созданных для _конкретного_ типа терминала. Это _реализация_ управления наследуемым кодом и его поведением.

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

M>когда в процессе разработке присутсвует этап code review, то даже маленькие кусочки приходиться писать задумываясь о архитектурной правльности этого кода.
M>кто-то скажет что это догматы и стереотипы, а кто то поймет что придерживаться стандартов, в том числе и архитектурных, это хороший стиль, это облегчает дальнейшее сопровождение и пр.

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

Как сказал один очень умный человек, посмотревший этот треп — спор ни о чем. Война догматов, практиков и теоретиков