Разрабатывается обычное декстоп приложение с возможностью портируемости на различные платформы (в очень далеком будущем... сейчас хотелось бы правильно сделать архитектуру, для чтобы когда настанет время — ничего не рефакторить).
GUI'ем для винды хочется взять творение питерских ребят из BCGSoft любезно предоставляемого Майкрософтом в рамках MFC Feature Pack for Visual C++ 2008.

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

Снйчас я вижу весь GUI приложения, как набор классов управляемых каким-то GUIManager'ом реализующим IGUIManager — в который агрегировано огромная куча интерфейсов — по интерфейсу для каждой группы семантически связанных контролов.
Основное приложение с помощью какой-то фабрики получает объект реализующий IGUIManager (свой для каждой реализации гуя на каждой платформе) — тем самым обеспечивая кроссплатформенность.

Приложения MFC сгенерированные виззардом построены по другому принципу — не буду писать всем и так известно.
Как адаптировать MFC приложение для моих нужд, как отделить GUI от логики в рамках MFC, чтобы GUI можно было как угодно менять (при условии сохранении реализации GUI'ем необходимых логике интефейсов) не затрагивая логики.

Пробую представить себе интерфейс такой надстройки — и не могу. Но я в архитектуре не силен. Традиционные библиотеки типа QT\WxW дают более низкоуровневое представление, на котором пишется интерфейс, а не наоборот — нечто глобальное, представляющее весь интерфейс. Если нет желание использовать готовые мультиплатформенные библиотеки, то имеет смысл идти от обратного — решаемую задачу представить в виде интерфейсов и писать платформо-независимую реализацию. А интерфейс писать родной для каждой платформы, вызывая оттуда реализацию.

есть такая концепция — MVC (model view controller). суть в следующем:
создаёшь интерфейсы для отображения графики — View
создаёшь интерфейсы для реагирования на действия юзера — Controller
свою прогу (Model) привящываешь к этим интерфейсам, а потом уже реализуешь гую, которая порлучается заточена под интерфейсы View и Controller.

например, почтовый клиаент.

class CModel
{
private:
CView *m_p_view;

public:
CModel(CView *p_view)
{
m_p_view = p_view;
}
void on_user_read_message(uint msg_id)
{
m_p_view->do_show_message(...);
}
...
};

class CView
{
virtual void do_show_message(string &msg) = 0;
};

показывать сообщение можно хоть в консоле — хоть в эдите. просто нужно написать соответсвующие реализации CView. зачастую View и Controller связывают в один класс — сообщения и уведомления в виндовс никак не разделены. тут главное — ничего лишнего View не закинуть в Model, иначе придётся потом переписывать.

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

J>Как адаптировать MFC приложение для моих нужд, как отделить GUI от логики в рамках MFC, чтобы GUI можно было как угодно менять (при условии сохранении реализации GUI'ем необходимых логике интефейсов) не затрагивая логики.

Теоретически, да — можно работать через интерфейсы типа IToolBar, IDockingPane и т.п. Но на практике, я думаю, это выльется в жуткий геморрой — в первую очередь из-за того, что внутреннее устройство различных GUI frameworks слишком различается.

Можно вывести всю работу с GUI в некий объект с методами CreateEnvironment(), HandleMouse(), HandleKey() и... что там еще? Короче — сделать "черный ящик", который будет целиком руководить UI. Но это все теория. На практике довольно трудно работать подобными "крупными мазками". И со временем, из-за множества компромиссов, все это хозяйство неизбежно обернется опять же страшным геморроем. Будет нечто "немножко зависимое тут", "немножко там", а что в результате? Несопровождаемый уродец.

В общем, ИМХО, данная задача — менять GUI frameworks "как перчатки" — близка к неподъемной. И я бы посоветовал не делать что-то "мульти-библиотечное", а посмотреть в сторону кроссплатформенных GUI-библиотек. Первое, на что я бы глянул, это Qt, особенно учитывая такие замечательные вещи, как Kinetic и QML. У вас есть блестящая возможность начать с нуля с использованием декларативного UI, а это дорогого стоит. Ну и, раз уж заговорили о декларативном UI, нельзя не упомянуть HTMLayout. Но там — только визуализация и с кроссплатформенностью пока не все ясно.