Facade外观模式(结构性模式)

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[];
            Wheel[] Wheels = new Wheel[];
            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模式注重稳定接口的情况下,为接口扩展功能.