tags:

views:

114

answers:

2

I've been writing a framework for myself in C# and my framework works on top of the Xna framework. In application code that uses this framework, I often have to include references to my framework and Xna's framework. Most of the time those Xna references are only to include some the struct classes like Vector2 and Rectangle. Because of this though, I try and make sure that the name's of my classes don't conflict with the name's of Xna classes. This can get tiresome and even confusing to myself when I have classes where I have come up with a similar name but not the same as the Xna one. (ie GamePadDevice and GamePad)

I've had an idea as of late but I don't know if it's worth it. I only use a few, 5 or 6 of the structs throughout my framework. Would it be worth it to abstract these structs away so that my application code would only have to deal with my framework? I could do this by either writing my own versions of the structs or inheriting from them or maybe someone could suggest a better way. Is the overhead worth simplifying my application code?

+2  A: 

I dont know how deep your framework goes on replacing the XNA layer, but if the user has no contact with XNA anymore, and is "just" using your framework, then it would be nicer if your framework only exposes his own structs to the client. After all, you might want to switch away from XNA one day and support XNB or XNC?

If you write a mapper in your framework that translates you will have the flexibility to do that later on

Heiko Hatzfeld
Can you elaborate on Mapper a little bit more? Are you referring to converter classes?
smack0007
A Mapper is basically something that converts types of X to types of Y. So in your scenario that would be converting between eg your own Vector2 and XNAs Vector2.
Peter Lillevold
Yes... Something that maps the XNA Data into your struct and back.
Heiko Hatzfeld
A: 

A good way to abstract away third party libraries is to introduce interfaces with methods you need and let the object creation be done by a Factory. Especially in your case, where you just use a bunch of the classes, this is, in my opinion, the best choice.

Lets assume we need to sanitize html code and do have a kickass library found which can do this for us, but we don't want to stick to this library - maybe somebody relases a super kickass lib someday we would like to use.

This could be implemented as follows (code in java )

First the interface definition:

public interface HtmlSanitizer {
      String sanitizeHtml(String html);
}

Then we create an concrete implementation for our interface, based on our kickass sanitizer

public class MyKickassHtmlSanitizer implements HtmlSanitizer {
    private com.foolib.kickass.html.Sanitizer delegate;

    public MyKickassHtmlSanitizer() {
      this.delegate= new com.foolib.kickass.html.Sanitizer();
    }

   public String sanitizeHtml(String html) {
    return delegate.kickassSanitizeHtml(html);
   }
}

Now the Factory which creates our sanitizer

public class HtmlSanitizerFactory {
      private static final HtmlSanitizerFactory instance = new HtmlSanitizerFactory();

      private HtmlSanitizerFactory() {}

      public static HtmlSanitizerFactory get() { return instance;}
      public HtmlSanitizer getSanitizer() {
          return new MyKickassHtmlSanitizer();
      }
}

To obtain an instance simply use:

 HtmlSanitizerFactory.get().getSanitizer();

Whereas the factory can provide static methods or not, can be a singleton or not. A matter of taste and use case.

Now your dependency to the libs kickass sanitizer is reduced to one point and to change the implementation simply introduce an SuperKickassHtmlSanitizer and let the factory return it.

Hope that helps :-)

Arthur