我要评论之前有阵子在业余时间拓展自己的一个游戏框架，结果在实现的过程中发现一个设计问题。这个游戏框架基于monogame实现，在monogame中，所有的材质渲染（texture rendering）都是通过spritebatch类来完成的。举个例子，假如希望在屏幕的某个地方显示一个图片材质（imagetexture），就在game类的子类的draw方法里，使用下面的代码来绘制图片：
protected override void draw(gametime gametime)
{
// ...
spritebatch.draw(imagetexture, new vector2(x, y), color.white);
// ...
}那么如果希望在屏幕的某个地方用某个字体来显示一个字符串，就类似地调用spritebatch的drawstring方法来完成：
protected override void draw(gametime gametime)
{
// ...
spritebatch.drawstring(spritefont, "hello world", new vector2(x, y), color.white);
// ...
}暂时可以不用管这两个代码中spritebatch对象是如何初始化的，以及draw和drawstring两个方法的各个参数是什么意思，在本文讨论的范围中，只需要关注spritefont这个对象即可。monogame使用一种叫“内容管道”（content pipeline）的技术，将各种资源（声音、音乐、字体、材质等等）编译成xnb文件，之后，通过contentmanager类，将这些资源读入内存，并创建相应的对象。spritefont就是其中一种资源（字体）对象，在game的load方法中，可以通过指定xnb文件名的方式，从contentmanager获取字体信息：
private spritefont? spritefont;
protected override void loadcontent()
{
// ...
spritefont = content.load<spritefont>("fonts\\arial"); // load from fonts\\arial.xnb
// ...
}ok，与monogame相关的知识就介绍这么多。接下来，就进入具体问题。由于是做游戏开发框架，那么为了能够更加方便地在屏幕上（确切地说是在当前场景里）显示字符串，我封装了一个label类，这个类大致如下所示：
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)
=> spritebatch.drawstring(_spritefont, text, position, textcolor);
}这样实现本身并没有什么问题，但是仔细思考不难发现，spritefont是从content pipeline读入的字体信息，而字体信息不仅包含字体名称，而且还包含字体大小（字号），并且在pipeline编译的时候就已经确定下来了，所以，如果游戏中希望使用同一个字体的不同字号来显示不同的字符串时，就需要加载多个spritefont，不仅麻烦而且耗资源，灵活度也不高。
经过一番搜索，发现有一款开源的字体渲染库：fontstashsharp，它有monogame的扩展，可以基于字体的不同字号，动态加载字体对象（称之为“动态精灵字体（dynamicspritefont）”），然后使用monogame原生的spritebatch将字符串以指定的动态字体显示在场景中，比如：
private readonly fontsystem _fontsystem = new();
private dynamicspritefont? _menufont;
public override void load(contentmanager contentmanager)
{
// fonts
_fontsystem.addfont(file.readallbytes("res/main.ttf"));
_menufont = _fontsystem.getfont(30);
}
public override void draw(gametime gametime, spritebatch spritebatch)
{
spritebatch.drawstring(_menufont, "hello world", new vector2(100, 100), color.red);
}在上面的draw方法中，仍然是使用了spritebatch.drawstring方法来显示字符串，不同的地方是，这个drawstring方法所接受的第一个参数为dynamicspritefont对象，这个dynamicspritefont对象是第三方库fontstashsharp提供的，它并不是标准的monogame里的类型，所以，这里有两种可能：
dynamicspritefont是monogame中spritefont的子类- fontstashsharp使用了c#扩展方法，对
spritebatch类型进行了扩展，使得drawstring方法可以使用dynamicspritefont来绘制文本
如果是第一种可能，那问题倒也简单，基本上自己开发的这个游戏框架可以不用修改，比如在创建label实例的时候，构造函数第二个参数直接将dynamicspritefont对象传入即可。但不幸的是，这里属于第二种情况，也就是fontstashsharp中的dynamicspritefont与spritefont之间并没有继承关系。
现在总结一下，目前的现状是：
dynamicspritefont并不是spritefont的子类- 两者提供相似的能力：都能够被
spritebatch用来绘制文本，都能够基于给定的文本字符串来计算绘制区域的宽度和高度（两者都提供measurestring方法） - 我希望在我的游戏框架中能够同时使用
spritefont和dynamicspritefont，也就是说，我希望label可以同时兼容spritefont和dynamicspritefont的文本绘制能力
很明显，可以使用gof95的适配器（adapter）模式来解决目前的问题，以满足上述3的条件。为此，可以定义一个ifontadapter接口，然后基于spritefont和dynamicspritefont来提供两种不同的适配器实现，最后，让框架里的类型（比如label）依赖于ifontadapter接口即可，uml类图大致如下：
dynamicspritefontadapter被实现在一个独立的包（c#中的assembly）里，这样做的目的是防止mfx.core项目对fontstashsharp有直接依赖，因为mfx.core作为整个游戏框架的核心组件，会被不同的游戏主体或者其它组件引用，而这些组件并不需要依赖fontstashsharp。
此外，同样可以使用c#的扩展方法特性，让spritebatch可以基于ifontadapter进行文本绘制：
public static class spritebatchextensions
{
public static void drawstring(
this spritebatch spritebatch,
ifontadapter fontadapter,
string text) => fontadapter.drawstring(spritebatch, text);
}其它相关代码类似如下：
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) => spritefont.measurestring(text);
public void drawstring(spritebatch spritebatch, string text)
=> spritebatch.drawstring(spritefont, text);
}
public sealed class fontstashsharpadapter(dynamicspritefont spritefont) : ifontadapter
{
public void drawstring(spritebatch spritebatch, string text)
=> spritebatch.drawstring(spritefont, text);
public vector2 measurestring(string text) => spritefont.measurestring(text);
}
public class label(string text, ifontadapter fontadapter) : visiblecomponent
{
// 其它成员忽略
public string text { get; set; } = text;
protected override void executedraw(gametime gametime, spritebatch spritebatch)
=> spritebatch.drawstring(fontadapter, text);
}总结一下：本文通过对一个实际案例的分析，讨论了gof95设计模式中的adapter模式在实际项目中的应用，展示了如何使用面向对象设计模式来解决实际问题的方法。adapter模式的引入也会产生一些边界效应，比如本案例中fontstashsharp的dynamicspritefont其实还能够提供更多更为丰富的功能特性，然而adapter模式的使用，使得这些功能特性不能被自制的游戏框架充分使用（因为接口统一，而标准的spritefont并不提供这些功能），一种有效的解决方案是，扩展iadapter接口的职责，然后使用空对象模式来补全某个适配器中不被支持的功能特性，但这种做法又会在框架设计中，让某些类型的层次结构设计变得特殊化，也就是为了迎合某个外部框架而去做抽象，使得设计变得不那么纯粹，所以，还是需要根据实际项目的需求来决定设计的方式。
到此这篇关于在c#中使用适配器adapter模式和扩展方法解决面向对象设计问题记录的文章就介绍到这了,更多相关c#面向对象设计内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论