5

I am working on a game project using Microsoft XNA framework, although this question is a generic one that involves decoupling of classes/systems.

Let's say i have a class (simplified to suit this example) as shown here:

public class GameCell
{   
        public Color Color { get; set; }
}

I would like to reuse as much code as i can between multiple platforms that use C#.

The problem of directly referncing the Color struct is that this type is defined in the XNA assemblies, creating a strong coupling (or dependency) between my code and XNA.

The other framework i will be using may (or may not) have its own Color object, with its own set of properties and API.

I would like to have the same source file "know" to use either the XNA or other framework's implementation automagically.

I know other types of decoupling methods such as IoC, but that would mean i would be plugging in different versions of a system/class, instead of reusing the same class in different contexts.

Is this even possible to do? how would u suggest to keep such a system portable?

I've seen some cases (in native C++ development) where you would define a set of classes that mirror the classes the framework you're using has (for example here - define Color again), and so it is possible to "re-map" this later on to use different classes, upon need.

Another option is to mess around using #IFDEF to play with the using statements in the header of the class (switching from XNA to other platforms). What is the best alternative in this case?

lysergic-acid
  • 19,570
  • 21
  • 109
  • 218
  • You should be clear about whether you require compatibility at the *source* or at the *assembly* level. If it's just source, then you can use conditional compilation. If it's binary assemblies, that's harder. – Craig Stuntz Dec 02 '11 at 20:18
  • For this specific requirement, i would like compatibility at the source level. I think that conditional compilation may get a bit messy and hard to maintain. I was wondering what other techniques exist. – lysergic-acid Dec 02 '11 at 20:22
  • Personally, I would just [re-implement the XNA types](http://andrewrussell.net/exen/) for your non-XNA platforms ;) – Andrew Russell Dec 03 '11 at 04:51
  • @liortal, I don't think what you want is possible. It might work for simple cases when you have a one-to-one mapping from one entity to another, but the overall design most probably won't have this simple mapping. Usually there are lots of objects interacting with each other in complex ways, so you won't be able to bring all this to a generic interface independent of the underneath implementation. Unless you build a higher-level layer on top of this. – Roman L Dec 03 '11 at 16:48

1 Answers1

5

Typically what you do is create your own Color structure and have it do the translation using conditional compilation switches. For example:

#define USE_DOTNET
//#define USE_SOMETHINGELSE

#if USE_DOTNET
using System.Drawing;
#endif

#if USE_SOMETHINGELSE
using SomethingElse.Drawing;
#endif

public struct MyColor
{
    #if USE_DOTNET
    Color TheColor;
    #endif
    #if USE_SOMETHINGELSE
    SomethingsColor TheColor;
    #endif

    public int R
    {
        get
        {
            #if USE_DOTNET
                // code to return .NET Color.R value
            #endif
            #if USE_SOMETHINGELSE
                // code to return SomethingColor.R value
            #endif
         }
    }
}

Another way is to have separate regions for the .NET and SomethingElse code. For example:

#if USE_DOTNET
public int R
{
    get { return TheColor.R; }
}
// other properties and methods here
#endif

#if USE_SOMETHINGELSE
// properties and methods for using SomethingElse
#endif

This can work well, but you have to be very careful when writing your code so that you don't use the .NET Color structure anywhere but in these portability layers.

We used this technique in C/C++ when developing games that had to run on Windows, the Mac, and several different game consoles. It's a pain to set up the portability layers, but once they're set up, it's pretty easy to use.

I would caution you, though, not to give your portability classes and structures the same names as classes or structures from the .NET libraries or the other libraries you're using. If you do that, you're going to confuse yourself, and you're likely to write some non-portable code that you won't discover until you start trying to port it. (Not that I'm speaking from experience or anything . . .)

Jim Mischel
  • 131,090
  • 20
  • 188
  • 351
  • This technique can work, however it forces me to map the exact APIs that actually need this and how they differ. For example, Color is defined in both APIs and both expose the R,G,B,A properties so here i would only need to have half of the code you demonstrated. For other cases i would have to map all shared classes to see how they differ. – lysergic-acid Dec 02 '11 at 20:25
  • @liortal: Of course you have to map the exact APIs. And, yes, doing so involves some work. You're trying to make two different things look the same. That's the whole point of the portability layer. There's no magic you can perform that will automatically do that mapping for you, and there's no way, in the general case, to avoid the mapping altogether. And don't be too hasty to share code among the different mappings. It's easy enough to do when you're only supporting two different platforms. But when you start supporting three or more, things get complicated in a hurry. – Jim Mischel Dec 02 '11 at 20:36
  • Another issue is that this adds the overhead of another method call for every access to the portability layer (MyColor.TheColor.R) – lysergic-acid Dec 02 '11 at 20:43
  • @liortal: You can fix that easy enough if you want. Rather than storing a .NET `Color` structure in your structure, copy the R, G, B, and A values into your structure. Basically, get the information you want from the other object, and store it yourself. I showed it the other way for simplicity. If performance is an issue, then you can optimize it any way you like. – Jim Mischel Dec 02 '11 at 20:54
  • Yes, just pointed that out. You gave some nice pointers to start with. I am actually thinking of using T4 templates to autogenerate some code. For the case of Color for example, XNA exposes Color.Green, Color.White etc which is just a fancy static way of getting RGBA values. i can easily reflect into that to automatically create that in a portable way. – lysergic-acid Dec 02 '11 at 21:03
  • Can you give an example how this technique can work for more than 2 frameworks ? (you said you've done this). Does the conditional compilation work for more platforms or it becomes a mess? – lysergic-acid Dec 03 '11 at 12:03
  • @liortal: To use for more than two frameworks, I'd go with the model that packs the code for each framework into a single conditional (i.e. my second example). That is quite tractable for multiple frameworks. The first example would be a nightmare of ugly code. I also would discourage sharing code among frameworks (i.e. nothing like `#if PLATFORM_1 || PLATFORM_3`. – Jim Mischel Dec 05 '11 at 23:50