I need to build a C++ application that works with both command line and graphical interfaces. I don’t want users to be stuck with one specific UI toolkit or have too many dependencies.
What’s the proper way to architect this? I’ve seen tools like Git and VNC that have different front-ends, but I’m not clear on the implementation approach. Would it be bad practice to create a GUI wrapper that just calls the core program using system calls?
I’m looking for clean design patterns that separate the business logic from the user interface layer. Any suggestions on how to structure the codebase would be helpful.
build a simple api layer that both UIs can hit. I’ve watched devs overcomplicate this forever. put your business logic behind the api, then create separate executables for cli and gui that call the same endpoints. way easier than trying to abstract everything from the start, and you can add new interfaces later without breaking existing stuff.
The trick is setting up a proper abstraction layer between your core logic and UI. I’ve done this with MVC for similar apps - just create an abstract interface that defines what your UI needs to do. Keep your business logic in the model layer, completely separate from any UI framework. Don’t use system calls though. They add overhead and make error handling a pain. Instead, compile your business logic into a static or shared library, then build thin CLI and GUI wrappers that use the same core classes. The only difference between GUI and CLI should be how they handle presentation and input. You’ll get better performance, cleaner error handling, and way easier debugging than trying to communicate between separate programs.
cool idea! why not try the observer pattern? what’s your app actually doing? the setup really depends on whether you need real-time syncing between interfaces or if they’re totally separate workflows. are you going cross-platform too?