Cross Framework Code Compatibility

[Gimel]

I am the middle of re-coding a older project and I wanted to move it to another GUI framework. Although at the moment I would like to redo the existing code to work with the old framework to improve efficiency and moldularity, then migrate over to the new framework which I still need to read up on.

Problem:

Because they are different frameworks, they have different ways of rendering their contents. This is my issue. If I rebuild around the existing GUI then I would have to go back and rewrite everything pertaining to rendering. I do not want to do this.

My Solution:

The current solution that I am thinking of using is making a wrapper class for the renderer and using macros within the class to use the correct implementation at compilation. This way I do not need to rewrite all the rendering methods in the main program, but rather write new implementations of the rendering object.

Is my solution any good and is this the proper way to approach this problem?

I know people call the use of macros a unsafe and dirty practice. Is it in this case?

[Gimmick]

Sounds like you're describing the adapter pattern. I'm not sure about using macros, but creating a wrapper for the renderer and abstracting it out is a perfectly legitimate strategy as far as I can see.

The only downsides being the reduced ability to reason about the code depending on how it's done - IIRC something similar was done in Rigs of Rods (a game) and the devs later stripped it out because it made the codebase too ugly/slow to run/some other reasons which I can't recall atm.

[Gimel]

At 4/23/19 12:51 PM, Gimmick wrote: Sounds like you're describing the adapter pattern. I'm not sure about using macros, but creating a wrapper for the renderer and abstracting it out is a perfectly legitimate strategy as far as I can see.

The only downsides being the reduced ability to reason about the code depending on how it's done - IIRC something similar was done in Rigs of Rods (a game) and the devs later stripped it out because it made the codebase too ugly/slow to run/some other reasons which I can't recall atm.

Very interesting. Until now, I really havn considered looking into programming design patterns because I didnt think it wasnt really needed. This situation has gotten me thinking that it is really more improtant than it seems. I wish my school would have emphasized a little more on design patterns as well instead of just raw programming ability.

[Gimmick]

At 4/27/19 12:56 PM, Gimel wrote:

At 4/23/19 12:51 PM, Gimmick wrote: Sounds like you're describing the adapter pattern. I'm not sure about using macros, but creating a wrapper for the renderer and abstracting it out is a perfectly legitimate strategy as far as I can see.

The only downsides being the reduced ability to reason about the code depending on how it's done - IIRC something similar was done in Rigs of Rods (a game) and the devs later stripped it out because it made the codebase too ugly/slow to run/some other reasons which I can't recall atm.

Very interesting. Until now, I really havn considered looking into programming design patterns because I didnt think it wasnt really needed. This situation has gotten me thinking that it is really more improtant than it seems. I wish my school would have emphasized a little more on design patterns as well instead of just raw programming ability.

It's important but not as much as you'd think. They're primarily methods used in large codebases to handle specific problems - like a manual of sorts for common problems. There's not much of a need to know all of them, just to recognize situations where they might be useful, and that's the sort of stuff that you'd probably only get through practice, not through theoretical learning. Even the given examples aren't very useful since there's no clear 1:1 mapping in real world code.

You definitely don't need to fit a design pattern all the time either, otherwise that too becomes an antipattern - "pattern driven design".