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

E>Кирилл, в том что вы говорите про решения Гради Буча и сейчас пытаетесь сказать про решения WolfHound-а просматривается одна и та же красная нить: мол отгребете вы, ребята, по полной, когда будете вынуждены свои иерархии расширять для поддержки новых требований.
К сожалению, как правило, "огребают" сопровождающий программист и компания, разрабатывающая программу, т.к. в связи с тем, что модель не расширяема, компании приходится либо отказываться от расширения функциональности, либо вкладывать кучу денег в то, чтобы полностью переделать решение. Последнее особенно несправедливо, т.к. расширяемость такого решения декларировалась разработчиком (там же интерфейсы, для них всегда можно создать другую реализацию).

E>И забываете простую штуку -- для того, чтобы появились эти самые новые требования, нужно здесь и сейчас получить работающее решение той конкретной задачи, которая была поставлена. Не больше, не меньше.
Расширяемость и повторное использование являются одними из критериев качества программы (привожу ссылку на классика ). Думаю, это не стоит сбрасывать со счетов.

E>Были в задаче Гради Буча именно такие датчики, он их объеденил в иерархию так, чтобы было не сложно и чтобы работало. Макаронный эфект там наблюдается, на вскидку, только в DisplayManager::display и все. Отказ от этого макаронного кода привел бы, скажем, к реализации Visitor-ов и усложнения датчиков. Т.е. решение Буча подчиняется простой идее: вовремя сделать минимально необходимый и минимально сложный код для решения конкретной задачи. Все остальные проблемы должны решаться по мере их поступления.
Если "плясать" от предложенной ОО-модели, то, действительно, ничего, кроме dynamic_cast'ов или Visitor'ов не остается. Но эти проблемы — прямое следствие предложенной модели. Если модель переделать, то код не усложниться, а dynamic_cast'ы и Visitor'ы не понадобятся.

Решение существует и для задачи с датчиками, и для задачи с кнопками и итемами. Если WolfHound'у будет интересно, это новое решение можно будет обсудить.