Skip to main content

Unity: How Adapters can help you write fewer MonoBehaviours

TL;DR: You don't need to duplicate a bunch of code to do the same things to a Image and a SpriteRenderer, or RectTransform and Transform, etc. You can use a simple pattern called the Adapter Pattern. If you've never used it before, this post explains how.

The Problem: Image vs SpriteRenderer

Lets say you want to make a sprite fade out, maybe its a dead monster or a collectible, but in either case you want it to gracefully depart from the screen rather than blink out of existence. Kinda like this eyeball monster from Beastly:


So that's pretty easy right, one way of doing it is with a MonoBehaviour that modifies the sprites alpha value via SpriteRenderer.color. Your class might look something like this:
public class AlphaFaderSprite : MonoBehaviour {
  public SpriteRenderer spr;
  public float fade_percentage;

  void Update() {
    spr.color = new Color(spr.color.r, spr.color.g, spr.color.b,
        fade_percentage);
  }
}
Now, anyone who's used Unity for more than an hour is now screaming internally at how inefficient the above class is. You'd never write code like this in reality, but for the sake of this tutorial lets ignore the specifics and keep things simple.

It is simple, right?

But what happens when you want to do the same thing to a UI element? Like a UI.Image?

Well that's easy too: we can just do the same thing we did for sprites and build a AlphaFaderUI:
public class AlphaFaderUI : MonoBehaviour {
  public Image img;
  public float fade_percentage;

  void Update() {
    img.color = new Color(img.color.r, img.color.g, img.color.b,
        fade_percentage);
  }
}
Great, but now alarm bells are ringing all up in your brain because you just wrote the same class twice.

The only difference between the two classes is that one works with Image and the other works with SpriteRenderer. Usually, this is where something like Polymorphism would come in handy, but unfortunately Image and SpriteRenderer meet in the class tree at Component, which doesn't provide a color member.

So how can we avoid this duplication? We could use Reflection, or if we were using a later version of C# we might use the dynamic keyword. The answer that I want to talk about is the Adapter Pattern.

The Adapter Pattern

First we define the adapter abstract base class, ColorAdapter, this promises to give us a way of modifying the color. This is what our generic components will use instead of SpriteRenderer or Image
public abstract class ColorAdapter {
  public abstract Color color { get; set; }
}
Next we subclass ColorAdapter for both Image and SpriteRenderer, these each simply delegate color modifications to their "adaptee" member variables.
public class AdaptedImage :  ColorAdapter {
  Image adaptee;

  public AdaptedImage(Image adaptee) {
    this.adaptee = adaptee;
  }

  public override Color color {
    get { return adaptee.color; }
    set { adaptee.color = value; }
  }
}

public class AdaptedSpriteRenderer : ColorAdapter {
  SpriteRenderer adaptee;

  public AdaptedSpriteRenderer(SpriteRenderer adaptee) {
    this.adaptee = adaptee;
  }

  public override Color color {
    get { return adaptee.color; }
    set { adaptee.color = value; }
  }
}
Now, in our alpha fade component we simply define AlphaFader to use a ColorAdapter.
public class AlphaFader : MonoBehaviour {
  public ColorAdapter ca;
  public float fade_percentage;

  void Update() {
    ca.color = new Color(ca.color.r, ca.color.g, ca.color.b,
        fade_percentage);
  }
}
And now we can write Alpha Fading logic once and use it for both component types. Mission accomplished.

Pros and Cons

You might be thinking
"We've ended up writing more lines of boilerplate code than we duplicated in the first place!"
... and you'd be right, but remember that this is a toy example. This class could also be used for any color manipulation (for example: flashing a sprite red when taking damage and "greying out"a shop item to signify that the player has insufficient funds could be the same component). If you've got a more complex series of color transformations the benefits are even greater.

We can add other functionalities to our adapter class, such as access to underlying Sprite or Material for even more flexibility. This might limit the number of Unity Components that can make use of the adapter, but that's only because its an abstract class. ColorAdapter doesn't actually need to be abstract, it can be an interface. Which means that you can create a myriad of different adapter types which something like a AdaptedImage can implement, further increasing coverage. An AdaptedImage could be an IColorAdapter, an ISpriteAdapter and an IMaterialAdapter all at once.

Beyond that, its easy to extend this to work with other components. We can define a Adapted3DRenderer for GetComponent<Renderer>().material.color manipulation and reuse our AlphaFade component for 3D objects, we can define a AdaptedText and fiddle with UI.Text colors.

One catch we do need to watch out for here: Where do we construct the ColorAdapters in the first place? For a simple Image/Sprite adapter it might be okay to have a couple of GetComponent<T>() calls in the Start() method of our alpha fading class:
  ColorAdapter ca;

  public void Start() {
    SpriteRenderer spr = GetComponent<SpriteRenderer>();
    Image img = GetComponent<Image>();

    if (spr != null) {
      ca = new AdaptedSpriteRenderer(spr);
    } else if (img != null) {
      ca = new AdaptedImage(img);
    }
  }
but it's easy to see that this might get annoying or complicated as we expand the range of possible adapters. We could try and do this in some kind of baseclass for classes that use the color adapters, but that would limit our ability to use multiple different types of adapter (e.g. some kind of TransformAdapter for RectTransform and Transform manipulation). Its clear that this would be a band-aid and not a solution.

The good news is that in practice this is (usually) a non-issue. This is because (usually) there will be an attached component which references your ColorAdapter holding component. In our first example, the dying monster, this would be the Monster class, which would be working with AlphaFade, we can pass responsibility for initialization to Monster.Start() instead, where we already know that we're dealing with a SpriteRenderer.

Wrapping Up

So, not bad right? The Adapter pattern is very simple, the type of thing that many of you might have already used without knowing it. I'm highlighting it here because I feel like small patterns like this are often overlooked in favor of more fancy techniques. There are larger versions of this problem where one might be tempted to use Reflection to facilitate a Duck Typing solution but, bar some minor issues, you're probably better off writing a little boiler plate and saving yourself the headache.

~Charles

Popular posts from this blog

Wacom vs N-Trig - A Modern Comparison

WARNING: This post is long. I wrote this because I could not find an unbiased comparison of the modern N-Trig and Wacom technologies online. It was written in response to the artistic outcry regarding the Surface Pro 3. If you are an artist, I believe it is worth reading.

UPDATED as of 20th June 2014 to reflect N-Trig software advancements.
UPDATED as of 23rd June 2014 to reflect new direct Digitizer comparison information.


Those of you who may visit this site regularly will know that I am a game developer, but what you might not know is that I also do a lot of sketching. (Maybe one day I will post the stuff online)

Since I am a geek, I do almost all of my sketching digitally, which means I am always looking out for new developments in digitizer technology. This brings me to this post in particular:

Following the announcement of the Surface Pro 3, many artists were shocked and disappointed by the news that the SP3 would be using N-Trig technology rather than Wacom technology like the SP…

[Pre-Alpha Peek] The Adventures of Clark Doud - Where Is Dark Cloud 3?

I Got Tired of Waiting for Dark Cloud 3So, I think most of the Fans of the Dark Cloud series are tired of waiting for a third installment (That is to say: Seriously where the hell is it?). So in the mean time I've decided to throw all my love for the series into making a Fan-game, because (You guessed it)They Should Have Made A Sequel.

So this audacious blend of (almost) copyright infringement and big talk isn't about taking on the gigantic task of filling the shoes of Dark Cloud 3, this is about giving myself something to play with until they make a sequel (...hopefully). Without further ado lets get into the meaty bit, what I've got so far: