.NET责任链模式(混合单例模式,模板方法模式)-----制作与扩展能力验证
.NET责任链模式、单例模式、模板方法模式混用
前言
哇,看到题目挺长的,这个组合型的东西,到底能干啥呢?本篇文章来一起琢磨琢磨,这两天为了团队的软件赶工,我负责的那一块叫:插件管理器。我们团队的成员用的语言还是挺分散的,本人C#,队长VB.NET,还有其他成员写易语言等,系统的功能插件是我们分开写的,各自用各自的喜欢的语言写各个功能模块的插件,最后用我开发的插件管理器把所有的插件整合到一起。这让我很头疼啊,一个C#版的插件,一个VB.NET版的插件,一个易语言的插件,如果有新成员加入,又来个Python版的插件,叫我如何是好。最普通、最烂的处理方法就是:写很多版本的读取器,然后使用if来根据插件语言使用对应该版本的读取器读取信息,哇,这如果来十几种语言,岂不是坑爹。可能有人会说:引入Kernel32能解决非.NET语言的插件读取吧。确实目前使用了这种方案,能兼容易语言,.NET语言就使用.NET的插件Dll读取方式,但是还不确定Kernel32能不能解决任何语言的插件。所以为了让自己有个后路,我结合题目所说的三种设计模式,写了一个模板,下面看这个模板能干嘛,为什么要这样用。如果有地方使用得不恰当的,希望各位朋友们强拍,我会努力学习改正,如果觉得可以的,点个推荐,谢谢~
框架展示与说明
大家看下类图,下面分别介绍各个类的职责。Plugin类是插件的数据结构类,PluginType是一个枚举,它的内容是定义了所有插件的类型,例如DotNet,Python等,扩展的时候需要修改该枚举。然后剩下的就是本章的重点了,用户代码Client使用IPluginAnalyzerable接口来读取插件信息,该接口有两个实现类,一个是PluginAnalyzer(抽象类,定义各个语言的读取器的公共部分),该类实现模板方法模式和责任链模式,让处理命令能在其子类之间互相推卸责任,其子类目前有两个,分别是DotNet,Python的具体读取器。最后一个类ComponentAnalyzer担任封装职责,将责任链初始化好,自己实现单例模式,提供给用户代码调用。所以,最后的效果是:获取ComponentAnalyzer的实例,调用其中一个方法,该方法调用具体读取器链,最后谁相应并且处理了这个方法调用用户是不知道的,大概思路就是这样。
实现过程
本实现过程只是模板的实现,具体应用到项目中还需要做出相应的改变。
事不宜迟,我们先实现Plugin类和PlugType枚举:
Plugin:
class Plugin { public Plugin(PluginType type,String pluginPath) { this.BelongType = type; this.PluginPath = pluginPath; } public PluginType BelongType { set; get; } public String PluginPath { set; get; } }
PlugType:
enum PluginType { DotNet=0, Python=1, }
实现完两个基本的类型以后,然后就来看下本篇的重头戏,我会边贴代码边附加上帮助理解的说明。首先从最高层的IPluginAnalyzerable开始:
interface IPluginAnalyzerable { void Analyze(Plugin plugin); }
用户代码就是使用该接口的Analyze方法来处理传入的插件的,再下一层有两个类,一个是抽象类PluginAnalyzer,一个是ComponentAnalyzer。
abstract class PluginAnalyzer:IPluginAnalyzerable { protected PluginType analyzerType; public void Analyze(Plugin plugin) { if (plugin.BelongType == this.analyzerType) { String author = GetAuthor(plugin); String version = GetVersion(plugin); Console.WriteLine(String.Format("\r\n分析者:{0},插件类型:{1} \r\n{2}\r\n{3}", this.GetType().Name,plugin.BelongType,author, version)); } else { if (nextAnalyzer != null) { nextAnalyzer.Analyze(plugin); } } } private PluginAnalyzer nextAnalyzer; public PluginAnalyzer NextAnalyzer { set { this.nextAnalyzer = value; } get { return this.nextAnalyzer; } } protected abstract String GetAuthor(Plugin plugin); protected abstract String GetVersion(Plugin plugin); }
解读:
每一个继承本类的具体类都有两个字段
1:所属类型(PluginType枚举),变量名为analyzerType。
2:下一个分析者(PluginAnalyzer),也就是兄弟类(同样继承PluginAnalyzer)。
每一个继承本类的具体类都需要重写两个方法GetAuthor和GetVersion,这两个方法将会在模板方法Analyzer内部被使用。
模板方法Analyzer首先判断传进来的插件类型是否和自身可以处理的类型相同,如果相同则调用自身的方法处理,如果不同则把处理权推给自己的下一位分析者。这样就完成了具体架构的搭建了。
然后就是具体读取器类了,各自有各自的处理相同任务的方式。都继承PluginAnalyzer
DotNetPluginAnalyzer(该类是处理.NET插件的读取器)
class DotNetPluginAnalyzer:PluginAnalyzer { public DotNetPluginAnalyzer() { base.analyzerType = PluginType.DotNet; } protected override string GetAuthor(Plugin plugin) { return "DotNet的插件,作者名为:Jarvin"; } protected override string GetVersion(Plugin plugin) { return "DotNet的插件,版本号为:!!!V2014!!"; } }
PythonPluginAnalyzer(该类是处理Python插件的读取器)
class PythonPluginAnalyzer:PluginAnalyzer { public PythonPluginAnalyzer() { this.analyzerType = PluginType.Python; } protected override string GetAuthor(Plugin plugin) { return "Python的插件,作者名为:Joker"; } protected override string GetVersion(Plugin plugin) { return "Python的插件,版本号为:V---很奇怪----"; } }
好了,如何使用?我将新建一个类,把这些读取器包装起来,并且形成一条链,提供一个统一的接口给用户代码调用,下面看我如何包装的。
ComponentAnalyzer
class ComponentAnalyzer:IPluginAnalyzerable { private ComponentAnalyzer() { rootAnalyzer = new DotNetPluginAnalyzer(); PythonPluginAnalyzer pythonAnalyzer = new PythonPluginAnalyzer(); rootAnalyzer.NextAnalyzer = pythonAnalyzer; } #region 单例模式实现 public static ComponentAnalyzer GetInstance() { return SingleHelper.GetInstance(); } private class SingleHelper { private static ComponentAnalyzer me = new ComponentAnalyzer(); public static ComponentAnalyzer GetInstance() { return me; } } #endregion PluginAnalyzer rootAnalyzer; public void Analyze(Plugin plugin) { rootAnalyzer.Analyze(plugin); } }
很简单的一个类,我们先看构造函数:把所有语言的读取器连接起来,然后链头是rootAnalyzer,我们每次调用Analyze方法都会调用rootAnalyzer对应的方法,让其在内部传递。弄到这里,差不多完成了,大家可以在最下面直接下载源码运行看结果,下面给出客户端测试类。
class Programe { public static void Main(string[] args) { IPluginAnalyzerable dotnetAnalyzer=ComponentAnalyzer.GetInstance(); Console.WriteLine("输入Q退出"); while(true) { Plugin plugin = RandomPlugin(); dotnetAnalyzer.Analyze(plugin); if (Console.ReadLine().ToUpper() == "Q") { break; } } } private static Plugin RandomPlugin() { Random random = new Random(); PluginType type = (PluginType)random.Next(0, 2); String plaginPath = Path.GetRandomFileName(); Plugin result = new Plugin(type, plaginPath); return result; } }
测试结果:看,以一致的方式执行,但是会得到不一样的效果,责任被推到合适的地方做出相应的处理。
到这里有人会说,那如何证明该模型的扩展性?? 好,下面我扩展一种语言读取器,看我改了多少,对系统影响了多少?
扩展性测试
我以Ruby为例。
1.在PluginType中添加一个枚举内容Ruby:。
2.添加一个Ruby读取器:
3.在ComponentAnalyzer(前面说的包装器)中,把该读取器添加到链条上!
为了测试,在客户端代码中修改Random随机生成数,使其能生成3,大功告成!(这是测试相关,我们没有修改实际客户端任何代码)
顺利扩展!!!我们修改的只是上层的代码,对于底层,也提供了扩展点,符合对修改封闭,对扩展开放。
总结
完成了,大家也累了,希望有不对的地方大家大力拍,面向组合编程,面向接口编程,不要面向具体实现类编程,这是我学习设计模式感受最深的一句话。谢谢大家观看。下面提供完整源码。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。