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

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

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

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

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

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