外观模式具体的代码和定义我就不多说了,希望了解或者重温的朋友可以翻看<<Head First设计模式>>,<<大话设计模式>>,<<研磨设计模式>>等都是不错的书籍。
我这里多从开发人员的角度阐述阐述。在大型项目的开发过程中,现场交付部门的研发人员经常使用公司研发部或者产品部的研发人员提供的各种基础功能包。现场开发能力强的人直接对照着基础功能包的使用手册就可以干活了,而往往由于人力成本的问题,现场还会有更多的刚入职的新手或者实习生,对于这些人也许才只能做到会用Java,让他们去学习略带业务的各种API几乎是无法完成的任务,这个时候抓狂的应该是现场的TeamLeader了。他除了手把手的教他们如何使用基础包外,还要面对这些菜鸟时不时的低级错误的问题来骚扰你。这种情况下你无法责怪研发部或者产品部的人不去提供一个将各个基础包都封装好的简单易用的API,因为他们的职责是满足现场所有可能的情况,进而提供的是足够多且足够满足各种场景的API。而现场也没有人有时间和精力去封装好一个简单易用的API。这其实是一种角色缺失。
还是从外观模式开始说起,从应用架构设计的角度,它是用来解决调用者(外部)与多个子系统(模块)的交互问题。效果是让调用者(外部)更简单的使用子系统,并且实现松耦合。其本质是封装交互、简化调用。
所以如果是没有碰到过上面困境的开发人员,一般情况下他是不会想到去需要外观模式的帮忙的。这个时候也许很多的IT从业人员就偷笑了,自己的学习能力理解能力还不差,一般情况下碰不到这种困境。可是如果我告诉你Android其实就是这么一个复杂难学的系统,你会觉得有点危言耸听了。你会说Android学习起来,使用起来没有那么难啊,很多人稍经培训就很快上手了呢。你说的确实没错,事情的表象就是没那么难,可你没看到事情的本质,事情的本质是google的工程师采用外观模式将复杂的东西全部封装好了,让你看到了一个简单易用的系统。
接下来我们从使用者的角度来感受下Android的易用性。Android的Context相信大家都非常的熟悉,而且都很会用,甚至都到了滥用的地步了。之所以不从底层开始讲起,然后描述一番其是如何设计Binder机制,以及一大堆的C/C++代码,最后通过JNI引申到我们常见的ServiceManager,ResourceManager,TelephonyManager等,最后再到我们熟知的Context以及startActivity。不是你们看晕了而是我晕了,而且从Android应用开发工程师实战应试的角度,也没有必要太了解这些。只要知道它的存在就好。
Context给我们带来了哪些易用性呢?
可以轻松的打开另一个Activity(甚至是别的应用的Activity,底层就是一种进程间通信你感受不到而已),
可以轻松 的调用startService和BinderService(这也是进程间通信你感受不到而已),
一般在工具类中会通过Context.getSystemService()获取到各种服务,进而获取到各种服务的相关信息,通过getResources()可以轻松的访问到各种资源,总之你用的到的用不到的,想的到的想不到的。只要是方便你调用Android各种资源和服务的,google工程师都帮你扔进了Context中。
相信读到这里,你会有兴趣自己去打开Android的源码android.content.Context.java去一探究竟的。
其实瞎忽悠了这些,我只是想说明一个问题,就是无数的开发人员经常面临的和碰到的一个疑惑,那就是知道设计模式很重要,仔细看看也能看懂,但就是在开发过程中不知道啥时候用到,怎么用到。