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

C>как-то слышал о концепции, в которой код разделяются на 3 части:

C>1. занимается только отображением графики
C>2. занимается только вычислениями
C>3. осуществляет взаимодействие первых двух

C>Что касается реализации. Допустим есть 3 класса: CAnyUi (гуя), CAnyCtrl (считалка), CAny (должен ими рулить). Допустим CAnyUi ловит оконное сообщение. есть обработчик этого сообщения CAnyUi::on_command(). это сообщение по идее, должен обработать CAnyCtrl. Так вот вопрос — как можно передать это сообщение CAnyCtrl не нарушив данной концепции?

C>1. заюзать множественное наследование: CAny : public CAnyUi, public CAnyCtrl. соответственно появляется возможность на своё усмотрение переопределять метод CAnyUi::on_command() и вызывать соответствующий метод CAnyCtrl.

C>2. добавить в CAnyUi колбек обработчик. то есть на on_command функция, которая уже вызывает соответствующий метод CAnyCtrl.

C>собственно вопрос. может я что-то упускаю? множественное наследование юзать неохота, да и с колбеками как-то криво получится...

Почитай про паттерны MVP [Model-View-Presenter] и MVC [Model-View-Controller] — выберешь, что тебе больше подходит.
А не хочешь, подписать на оконное событие сам CAny [Presenter] (по-хорошему — на событие CAnyUi [View], которое делегирует оконное событие)?
Идея "разделения на 3 части" предполагает повышение заменяемости модулей — "провязывание" зависимостей через интерфейсы, а не через классы.
И для уменьшения количества зависимостей (пусть и от интерфейсов), надо стараться делать так, чтобы только Presenter "знал" про модели [Model] и представления [View], а они про него — нет.
Т.е. вызывать метод CAnyCtrl из CAnyUi — не есть хорошо.
Также, как и делать мешанину, наследуя презентер от модели и представления...