中间件架构——思考总结（长期记录系统中的设计模式应用）

一、Onos 中间件中的依赖倒置、开闭原则、工厂模式

（1）遵循依赖倒置，即面向接口编程的原则

我们的 onos 中间件的类要提供给西电方使用，那么我们的类要尽量有抽象类或者接口（遵循依赖倒置，即面向接口编程的原则），或者说这个接口本来就是西电方给我们设置的，定义他们需要的方法，我们的实现类实现这些接口，当需求改变时，我们增加新的实现类即可，比如西电方现在需要我们提供支持新版本openflow 协议的类时，我们只需要新增一版类即可。

（2）依赖工厂模式向高层代码屏蔽具体子类类型

另外，联系到工厂模式，西电方定义的接口实际上就是他们需要的抽象产品，而我们的具体实现类实际上就是具体产品，如果我们需要将具体产品的类型向西电方进行屏蔽的话，使得他们不需要掌握具体产品类名等就可以获取相应具体产品，那我们我们应该增加工厂设计：

（1）如果西电方需要通过向工厂传入某个参数而获取某个对象的话，就可以使用简单工厂模式，即定义一个工厂类， create 方法获取西电方参数，根据参数返回具体产品；

（2）如果西电方需要通过向工厂传入参数（或者实例化具体工厂）而获取一系列对象的话，就可以使用抽象工厂模式：具体来说，就是我们可以定义一个抽象工厂类，西电方通过该抽象工厂引用具体工厂，具体工厂中实现了所有类型对象的创建方法，西电方调用一系列具体产品的对象获取方法，获取相应对象。

我们考虑的是抽象工厂，因为我们的需求是：1.我们会针对多种的 openflow 版本实现多种类型，如针对 openflow1实现A1、B1、C1，再针对openflow2实现A2、B2、C2，A1和 A2是 实现了抽象产品 A 的具体产品 2.西电方本身是一套依赖A、B、C 的复杂逻辑，需要依赖具体工厂对A、B、C 的具体产品进行获取，如当前西电逻辑想依赖于 A3、B3、C3了，那就利用 实现了抽象工厂的具体工厂Factory3，来创建相应的具体产品（他们只需要知道他们用的是3系列对应的工厂即可，当需要再替换依赖版本是，修改抽象工厂引用的具体工厂对象即可啦）。