子墨对酒《三国杀》里论模式(二)门面模式

学习模式的人对门面模式都不会太陌生，如果说工厂模式是对对象的高层次抽象的话，那么门面模式就是对对象，就是一种更高层次的抽象。这么说可能不好理解，我们举个很好理解的例子，我们知道cpu的目的是为了运算，而运算我们又分成解释和计算。这分别是由解释器对象和运算器对象完成。而对于外部电路来说根本不了解解释器对象和运算器对象的存在。也就是说cpu将整个的逻辑过程都封装在自己内部。只暴露给用户一个简单的计算接口。这就是门面模式。还有一个非常浅显的例子就是GUI的界面编写，我们大部分编写应用的时候大都采用MVC的设计框架。或者可以说我们在写界面的时候是完全可以脱离业务逻辑而存在的。当我们为了完成一个按钮的功能的时候,我们常常只关心这个按钮所提供的单个接口,而不关心内部的细节。这样就避免了所谓的接口泛滥。比如说,我们有一个保存的按钮,实际上我们只希望调用save接口就能完成所有的事情。至于你save接口里面采用的究竟是数据库,文件,还是云的方式根本就不关心,在存储之前和之后要做的业务逻辑处理有业务处理模块来完成。对gui的设计者而言,看到只有save的这个门面接口。不知道大家这时候是否恍然大悟？是否捶胸顿足，原来我之前写的代码形式就是按门面模式的方式在写。是的，其实大家不用把设计模式想成一门学科，它就是一门艺术，或者说一种编写模式。它是对人们编写代码的一种抽象。大家不理解模式是因为并没有将你自己写的写法进行抽象，所以你认为你写的东西没有一点模式，其实是完全错误的，你之所以这么写，一定是有一种模版在你脑子里面。回头我们再聊一下门面模式，如果说门面模式是对系统的更高层次的抽象，那么工厂模式是否可以称之为一个门面呢？我个人觉得你要从概念上来说也是合理的。但是工厂的侧重在构造，而门面的的要点在封装，而且是高层次的封装。我不知道我刚才说得模式的理解是否打动了你们？我说一个简单的例子，我翻看某博主写的单例模式的理解的时候将内存问题也归咎于模式本身，因为模式本身就是一种抽象，又何来问题之有。而且从功能性来说，单例模式本身就是要有一个不变的持有对象，对象释放才是怪事。我希望我们在探讨模式的时候是先理解模式的概念，而不是写了一行代码就认为代表模式，然后在代码上吹毛求疵。。当然，模式从不同的角度有不同的观点，还是那句话，你从你的角度上看，可能有不同的抽象风景。每个空间,每个时间我们可能从相同的代码中可以看到不同的代码模式。我们回到《三国杀》这款游戏来。显而易见,三国杀是一个GUI的程序。在刚打开程序的时候就有让你选择服务器的选项，这就是一个网络服务的门面；

我们现在理性的来分析这个小功能,实际上对于GUI系统来说只希望有一个登陆的业务模块,这个登陆的模块能完成所谓的不同的服务区域的对接；我们姑且定义这个类为

class LoginAction {

     public void login(long id);//参数为服务器编号

}

对于Gui层只调用控制层,而控制层来说只用调用LoginAction.login()就完成操作了.当然我们知道login里面可能有很多的业务逻辑。我们假定有下列的逻辑：

login(){

    InetChecker.check()//检查网络

    PersonNumberChecker()//服务器负载人员检查

    loginnow();//服务器登陆

    Controller.gotoOtherPage();//跳转到另外一个UI界面

}

可见,一个简单的登陆接口可能要跟很多的系统打交道。而如果把这些逻辑都放在控制层,或者说是调用者。那么意味着你就要跟多个系统模块打交道。无形中增加了你模块之间的耦合度。举个很简单的例子,假如说我对服务器负载的检查变更了接口,需要多传递几个参数,或者说要变更成一个新的模块。那么你之前硬编码到代码中的那些代码就成了无用类。门面是对系统的高层抽象,它存在的目的是为何调和系统直接的相互调用的关系。至于在某些书中提到的要将门面写成单例的我觉得其实是没有必要的。当然具体问题当然要具体分析。

--非子墨

微博账号: 非子墨
QQ:1025250620

CSDN:《非子墨》的空间