1、系统的复杂度
需求:开发一个坦克模拟系统用于模拟坦克车在各种作战环境中的行为,其中坦克系统由引擎、控制器、车轮等各子系统构成.然后由对应的子系统调用.
常规的设计如下:
#region 坦克系统组成
/// <summary>
/// 引擎类
/// </summary>
public class Engine
{
public void EngineActionA() { }
public void EngineActionB() { }
}
/// <summary>
/// 车轮
/// </summary>
public class Wheel
{
public void WheelActionA() { }
public void WheelActionB() { }
}
/// <summary>
/// 控制器
/// </summary>
public class Controller
{
public void ControllerActionA() { }
public void COntrollerActionB() { }
}
#endregion
/// <summary>
/// 游戏系统
/// </summary>
public class GameSystem
{
/// <summary>
/// 引擎初始化类
/// </summary>
public class EngineInit
{
/// <summary>
/// 引擎初始化,并将控制权交给控制器
/// </summary>
public void Init()
{
var engine = new Engine();
var controller = new Controller();
}
}
/// <summary>
/// 车轮初始化类
/// </summary>
public class WheelInit
{
/// <summary>
/// 车轮初始化,并将控制权交给控制器
/// </summary>
public void Init()
{
var engine = new Wheel();
var controller = new Controller();
}
}
}
ok,这是最简单的实现,完成了游戏系统对坦克系统的调用,将上面的系统调用抽象成一张构成图,如下:
可以发现,坦克系统的各个组成部分,柔和到了游戏系统的各个类型中,这种设计一旦坦克的组成部分发生变化,所造成的维护成本是十分昂贵的!
2、问题
组件(坦克系统)的客户端调用程序(系统系统)和组件中各种复杂的子系统之间产生了过多的耦合,随着外部客户程序和组件各子系统的演化,这种耦合产生的维护成本十分昂贵.
3、解决方案
必须抽象出一层接口,这层接口需要将坦克系统进行抽象,并告诉游戏客户端哪些功能,是它可以调用的,而不是让系统系统自己去调用坦克系统的组件来实现相关的功能,将组件系统(坦克系统)和外部调用客户程序(游戏系统)的变化之间的依赖解耦.将这种变化成本交给这层接口来承担.
#region 坦克系统组成
/// <summary>
/// 引擎类
/// </summary>
internal class Engine
{
public void EngineActionA() { }
public void EngineActionB() { }
}
/// <summary>
/// 车轮
/// </summary>
internal class Wheel
{
public void WheelActionA() { }
public void WheelActionB() { }
}
/// <summary>
/// 控制器
/// </summary>
internal class Controller
{
public void ControllerActionA() { }
public void COntrollerActionB() { }
}
#endregion
public class TankFacade
{
//注入相关坦克系统的组件,如果引擎、车轮这些可能会有风格的变化,可以考虑使用工厂模式来实现注入
Engine[] Engines = new Engine[6];
Wheel[] Wheels = new Wheel[6];
Controller Controller = new Controller();
/// <summary>
/// 坦克的启动功能,完成引擎、控制器的初始化.
/// </summary>
public void Start()
{
}
/// <summary>
/// 坦克的停止功能,完成引擎、控制器的停止
/// </summary>
public void Stop()
{
}
}
客户端调用代码如下:
/// <summary>
/// 游戏系统
/// </summary>
public class GameSystem
{
private TankFacade tankFacade = null;
/// <summary>
/// 开始游戏
/// </summary>
public void Run()
{
TankFacade facade = new TankFacade();
facade.Start();
}
/// <summary>
/// 结束游戏
/// </summary>
public void Stop()
{
if(tankFacade!=null)
tankFacade.Stop();
throw new Exception("引擎未启动,无法停止!");
}
}
通过TankFacade类,将坦克系统的组件集成到里面,提供给游戏系统它所需要的功能,很好的实现了客户端调用系统依赖与坦克组件的问题,完成了解耦.解耦后的结构图如下:
4、要点
(1)、从客户程序的角度来看,Facade模式补不仅简化了整个组件系统的接口,同时对于组件内部与外部客户程序来说,达到了一种解耦的效果,内部子系统的变化不会影响到Facade接口的变化.
(2)、Facade模式更注重从架构的层次去看待整个系统,而不是单个类的层次,更多的时候是一种架构设计模式.
(3)、Facede模式与Apater模式、Bridge模式、Decorator模式的区别,Facede模式注重简化接口,Apater注重转换接口(将现有接口转换成客户需要的接口),Bridge模式接口的分离(即系统按照两个维度及以上的变化适合使用Bridge模式),Decorator模式注重稳定接口的情况下,为接口扩展功能.