Location>code7788 >text

Solving Object-Oriented Design Problems with the Adapter Pattern and Extension Methods in C#

Popularity：855 ℃/2024-10-07 19:17:35

A while ago, I was expanding a game framework of my own in my spare time, and I found a design problem in the process of implementing it. This game framework is based onMonoGameimplementation, in MonoGame all texture rendering (Texture Rendering) is done via theSpriteBatchclass to accomplish this. For example, if you want to display an imageTexture somewhere on the screen, you would add a class to theGameof a subclass of the classDrawmethod, use the following code to draw the image:

protected override void Draw(GameTime gameTime)
{
    // ...
    (imageTexture, new Vector2(x, y), );
    // ...
}

Then if you want to display a string in a certain font somewhere on the screen, similarly call theSpriteBatch(used form a nominal expression)DrawStringmethod to accomplish this:

protected override void Draw(GameTime gameTime)
{
    // ...
    (spriteFont, "Hello World", new Vector2(x, y), );
    // ...
}

For the time being, you can leave the two code inspriteBatchHow the object is initialized, andDrawcap (a poem)DrawStringWhat the individual parameters of the two methods mean is, for the purposes of this discussion, only of interest to thespriteFontMonoGame uses a technique called Content Pipeline to compile various resources (sounds, music, fonts, textures, etc.) into thexnbfile, after which it is passed through theContentManagerclass that reads these resources into memory and creates the corresponding objects.SpriteFontis one of the resource (font) objects in theGame(used form a nominal expression)Loadmethod, you can specify thexnbThe filename is derived from theContentManagerGet font information:

private SpriteFont? spriteFont;
protected override void LoadContent()
{
    // ...
    spriteFont = <SpriteFont>("fonts\\arial"); // Load from fonts\\
    // ...
}

OK, that's all there is to know related to MonoGame. Next, let's get into the specifics. Since I'm doing a game development framework, in order to make it easier to display strings on the screen (in the current scene, to be exact), I've wrapped up aLabelclass, which is shown roughly as follows:

public class Label : VisibleComponent
{
    private readonly SpriteFont _spriteFont;
    
    public Label(string text, SpriteFont spriteFont, Vector2 pos, Color color)
    {
        Text = text;
        _spriteFont = spriteFont;
        Position = pos;
        TextColor = color;
    }

    public string Text { get; set; }
    public Vector2 Position { get; set; }
    public Color TextColor { get; set; }

    protected override void ExecuteDraw(GameTime gameTime, SpriteBatch spriteBatch)
        => (_spriteFont, Text, Position, TextColor);
}

There is nothing inherently wrong with this realization, but on reflection it is easy to see that theSpriteFontThe font information is read from the Content Pipeline, and the font information contains not only the font name, but also the font size (font size), and in the Pipeline compilation time has been determined, so if the game wants to use the same font with different font sizes to display different strings, you need to load multiple SpriteFont, which is not only troublesome, but also resource-consuming, and not flexible. This is not only troublesome but also resource-consuming and not very flexible.

After some searching, I found an open source font rendering library:FontStashSharpIt has a MonoGame extension that can dynamically load font objects based on different font sizes (called "Dynamic Sprite Fonts").DynamicSpriteFont"), then use MonoGame's nativeSpriteBatchDisplays the string in the scene in the specified dynamic font, for example:

private readonly FontSystem _fontSystem = new();
private DynamicSpriteFont? _menuFont;

public override void Load(ContentManager contentManager)
{
    // Fonts
    _fontSystem.AddFont(("res/"));
    _menuFont = _fontSystem.GetFont(30);
}

public override void Draw(GameTime gameTime, SpriteBatch spriteBatch)
{
    (_menuFont, "Hello World", new Vector2(100, 100), );
}

upperDrawmethod, which still uses themethod to display the string, the difference being that thisDrawStringThe first parameter accepted by the method isDynamicSpriteFontobject, thisDynamicSpriteFontThe object is provided by a third-party library, FontStashSharp, and it's not a type found in the standard MonoGame, so there are two possibilities here:

  1. DynamicSpriteFontIt's in MonoGame.SpriteFontsubclass of
  2. FontStashSharp uses a C# extension method for theSpriteBatchtype has been extended so that theDrawStringThe method can be accessed using theDynamicSpriteFontto draw text

If it's the first possibility, then the problem is simple, basically, you can develop this game framework by yourself without any modification, for example, in the creation of theLabelinstances, the second argument to the constructor directly sets theDynamicSpriteFontobject is passed in just fine. But unfortunately, this falls into the second category here, which is the FontStashSharpDynamicSpriteFonttogether withSpriteFontThere is no inheritance relationship between

Now to summarize, the current state of affairs is:

  1. DynamicSpriteFontis notSpriteFontsubclass of
  2. Both offer similar capabilities: both are capable of beingSpriteBatchare used to draw text, both are able to calculate the width and height of the drawing area based on a given text string (both provide aMeasureString(Methods)
  3. I would like to be able to use both in my game frameSpriteFontcap (a poem)DynamicSpriteFontThat is, I want Label to be compatible with both theSpriteFontcap (a poem)DynamicSpriteFonttext-drawing capabilities

Obviously, it's possible to use GoF95'sAdapter modeto solve the current problem to fulfill the conditions of 3 above. For this purpose, it is possible to define aIFontAdapterinterface, and then based on theSpriteFontrespond in singingDynamicSpriteFontto provide two different adapter implementations, and finally, let the types in the framework (such as theLabel) is dependent onIFontAdapterinterface is sufficient, the UML class diagram is roughly as follows:

DynamicSpriteFontAdapteris implemented in a separate package (Assembly in C#), the purpose of this is to prevent the project from having a direct dependency on FontStashSharp, because as the core component of the whole game framework, it will be referenced by different game bodies or other components that don't need to depend on FontStashSharp.

In addition, it is also possible to use C#'s extension method feature to make theSpriteBatchThis can be done based on theIFontAdapterPerform text drawing:

public static class SpriteBatchExtensions
{
    public static void DrawString(
        this SpriteBatch spriteBatch, 
        IFontAdapter fontAdapter, 
        string text) => (spriteBatch, text);
}

Other related codes are similar as below:

public interface IFontAdapter
{
    void DrawString(SpriteBatch spriteBatch, string text);
    Vector2 MeasureString(string text);
}

public sealed class SpriteFontAdapter(SpriteFont spriteFont) : IFontAdapter
{
    public Vector2 MeasureString(string text) => (text);

    public void DrawString(SpriteBatch spriteBatch, string text)
        => (spriteFont, text);
}

public sealed class FontStashSharpAdapter(DynamicSpriteFont spriteFont) : IFontAdapter
{
    public void DrawString(SpriteBatch spriteBatch, string text)
        => (spriteFont, text);

    public Vector2 MeasureString(string text) => (text);
}

public class Label(string text, IFontAdapter fontAdapter) : VisibleComponent
{
    // Other members ignore
    public string Text { get; set; } = text;

    protected override void ExecuteDraw(GameTime gameTime, SpriteBatch spriteBatch)
        => (fontAdapter, Text);
}

To summarize:This article discusses the application of the Adapter pattern of GoF95 design patterns in real projects through the analysis of a real case, showing how object-oriented design patterns can be used to solve real problems.The introduction of the Adapter pattern also produces some boundary effects, such as in this case FontStashSharp'sDynamicSpriteFontIn fact, it can also provide more rich functionality, but the use of the Adapter pattern, so that these features can not be fully used by the homemade game framework (because the interface is unified, and the standard SpriteFont does not provide these features), an effective solution is to extend theIAdapterinterface's responsibilities, and then use theempty object modelto complement the functionality of an adapter is not supported in the features, but this approach will be in the framework design, so that certain types of hierarchical design to become specialization, that is, in order to cater to an external framework to do the abstraction, so that the design has become less pure, so, still need to be based on the needs of the actual project to determine the design of the way.

<Previous Next>