I have some windows c++ code (pure winapi c++, no MFC etc) that I would like to build a GUI for. My code does not know about windows GUI, it is completely decoupled from any type of UI.

The question: How could I build a UI around the existing code. Ideally, I am imagining something like this:

GUI <--> Mediator <--> MyExistingCode

For example,

MyExistingCode.showmsg(char* msg) would call Mediator.MessageBox(0, 0, msg, 0);

I'm stuck at how to design the Mediator class (If that is the correct way of going about this). Is the Mediator an Interface?, Abstract Class?, Other? Is an MVC model the best way to go?

  • Does it matter at this point? The most important thing would be to get the decoupling done in any way shape or form. As you go you will find advantages and drawbacks to the way you have chosen to go and can adjust. Yes you may have to rework what you have already done, but that shouldn't be too hard or too much work as the code is already decoupled... – Marjan Venema Feb 2 '14 at 13:28

The solution that works best for me nowadays is to build my application like a library (lib or dll) and then build my console or GUI application on top of that. On Visual Studio, for example, this works by having (at least) two projects in the same solution. One project is your library and the other is the consumer of that library. You only have to provide a sensible interface, and not care who and how it uses your library. In this way, my console or GUI would use my code as any other regular 3rd party library.

See some opinions on this SO question: What do you think of developing for the command line first?


Start with one of the MVC, MVP or MVVM patterns. All of these are proven and have their own advantages and disadvantages. There's plenty of literature out there and even here on SO/SE.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.