Android开发设计模式02

单例模式，可以说是GOF的23种设计模式中最简单的一个。
这个模式相对于其他几个模式比较独立，它只负责控制自己的实例化数量单一(而不是考虑为用户产生什么样的实例)，很有意思，是一个感觉上很干净的模式，本人很喜欢这个模式。
android中很多地方都用到了单例模式，本文以输入法管理者InputMethodManager为例，展开分析。
单例模式，Singleton Pattern,能够以其特有的优势，替代系统中全局变量，应用非常广泛。

1.意图
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
热门词汇：单例 唯一 私有构造

2.结构

android中有很多系统级别的全局变量，如时间，输入法，账户，状态栏等等，android中对这些都直接或者有些间接用到了单例模式。
以输入法为例，把上图修改为实际情况：

非常的简单，但是有一点，从上面我们也看到了synchronized关键字，在多线程的环境下，单例模式为了保证自己实例数量的唯一，必然会做并发控制。
类似这种线程安全的单例，跨进程的单例，参数化的单例等等的情况，确实超出本文的范围，而且都涉及到很多东西，是一个很大的话题，不好展开。

3. 代码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

public final class InputMethodManager {     static final Object mInstanceSync = new Object();//同步     //内部全局唯一实例     static InputMethodManager mInstance;       //对外api     static public InputMethodManager getInstance(Context context) {         return getInstance(context.getMainLooper());     }           /**      * 内部api，供上面的外部api调用      * @hide 系统隐藏的api      */     static public InputMethodManager getInstance(Looper mainLooper) {         synchronized (mInstanceSync) {             if (mInstance != null) {                 return mInstance;             }             IBinder b = ServiceManager.getService(Context.INPUT_METHOD_SERVICE);             IInputMethodManager service = IInputMethodManager.Stub.asInterface(b);             mInstance = new InputMethodManager(service, mainLooper);         }         return mInstance;     } }

　　客户端调用，比如contextimpl中的getSystemService()方法中如下调用：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

class ContextImpl extends Context{     @Override     public Object getSystemService(String name) {         if (WINDOW_SERVICE.equals(name)) {             //... ... 省略下面n个if，else if         } else if (INPUT_METHOD_SERVICE.equals(name)) {             //获取输入法管理者唯一实例             return InputMethodManager.getInstance(this);         }  else if (KEYGUARD_SERVICE.equals(name)) {              //... ... 省略下面n个if，else if         } else if (ACCESSIBILITY_SERVICE.equals(name)) {             //又见单例，无处不在             return AccessibilityManager.getInstance(this);         } else if (LOCATION_SERVICE.equals(name)) {             //... ... 省略下面n个if，else if         }  else if (NFC_SERVICE.equals(name)) {             return getNfcManager();         }         return null;     } }

　　非常简单，干净的一个模式。

4.效果
(1).创建型模式。
(2).对唯一实例的受控访问。
(3).避免全局变量污染命名空间。
(4).允许对操作和表示的精化。
(5).比类操作更灵活。 

----------------------

模板方法，和单例模式是我认为GOF的23中最简单的两种模式。
但是我个人对模板方法的经典思想特别推崇，虽然模板方法在大对数情况下并不被推荐使用，但是这种通过父类调用子类的方法，使用继承来改变算法的一部分，是面向对象的一种基本认识。
打比方说父亲有很多理想，就行医救人吧，但是父亲医术不行，只能靠儿子，儿子长大后遵从父亲大志，春风拂面，妙手回春，实现了父亲的理想，儿子做的事情早在出生前就定下来了，是父亲之前久定好的模板。
认识到模板方法的这种思想，父类可以让未知的子类去做它本身可能完成的不好或者根本完成不了的事情，对框架学习大有帮助。
本文以View中的draw方法为例，展开分析。
模板方法，TemplateMethod，光是学习这个模式，就会对你产生长远影响的一个模式。

1.意图
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 
热门词汇：骨架 步骤 结构 延迟到子类 

2.结构 

定义了几个步骤1,2,3等，在模板方法中按照一定的结构顺序执行这些步骤。父类的方法可以有缺省实现，也可以是一个空实现，即所谓的钩子操作。
结合实际情况，我们画出View中draw方法涉及到的几个步骤方法如下：

学习模板方法对于我们了解框架的基类实现，生命周期和流程控制非常有帮助，我觉得是务必要掌握的一个模式。

3.代码

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

public class View{     /**      * 钩子操作，空实现      */     protected void onDraw(Canvas canvas) {     }       /**      *钩子操作，空实现      */     protected void dispatchDraw(Canvas canvas) {     }       //算法骨架     public void draw(Canvas canvas) {        if (!verticalEdges && !horizontalEdges) {             // 步骤1             if (!dirtyOpaque) onDraw(canvas);               // 步骤2             dispatchDraw(canvas);               // 步骤3             onDrawScrollBars(canvas);               return;         }     }     //... ... }

　　我们看看系统组件TextView的实现：

1 2 3 4 5 6

public class TextView{     @Override     protected void onDraw(Canvas canvas) {         //大量自定义实现代码     } }

　　如果我们自定义View的话，我们一般也是重写onDraw方法即可：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class MyView extends View {       public MyView(Context context) {         super(context);     }       @Override     protected void onDraw(Canvas canvas) {         super.onDraw(canvas);     }       @Override     protected void dispatchDraw(Canvas canvas) {         super.dispatchDraw(canvas);     }       }

4.效果
(1).模板方法是一种代码复用的基本技术。它们在类库中尤为重要，它们提取了类库中的公共行为。
(2).模板方法导致一种方向控制结构,"好莱坞法则"："Don't call me,i will call you.",即一个父类调用子类的操作，而不是相反。
(3).模板调用操作的类型有具体的操作，具体的AbstracClass操作，原语操作，工厂方法，钩子操作。少定义原语操作。
(4).android中对这些重定义操作的命名喜欢在方法前加一个前缀on。
(5).模板方法使用继承来改变算法的一部分。策略模式使用委托来改变整个算法。

----------------------------

备忘录模式，在工作代码中，要么不用，要么经常用到。
举个例子，程序员喜欢写代码，coding,coding,这个时候它的状态是很high，但是每隔一段时间总要去上一下厕所，状态是放松relax，上完测试归来后又恢复到high的状态，继续coding。这个过程对于身后的老板来说，它默认同意你离开去上厕所，他也希望你回来后恢复high的状态继续工作，但是你在这个过程中上厕所的这件事，他是不需要了解细节的，而且做为当事人你也不希望他了解你上厕所的细节吧，你只要回来后恢复激情high着继续工作，老板应该就不会挑你的刺。
这就是备忘录模式。
本文今天就Canvas的一个save(),restore()操作分析一下，但是有一点，看完本文，如果不懂备忘录模式的，应该还是不懂，但是canvas是android的一场大戏，说一说它的特色，对深入学习android绝对有帮助。
学习备忘录模式，通过保存状态，恢复状态的内部实现，对了解一些莫名其妙的看上去无用其实很重要的操作有拨开云雾见青天的作用。

1.意图
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可以将该对象恢复到先前保存的状态。
热门词汇：标记 状态 备忘录 原发器

2.结构和代码

组织者，把原发器的状态State（全部或者部分状态，一般是变量的值），通过CreateMemento()方法保存起来，继续运行后，等待合适的时机，在通过SetMemento()方法可以再次恢复到之前的状态。在这个过程中，我们并没有对这些状态做任何的访问和设置，实际上这些状态都是私有的，对外是禁止访问的，我们只是通过Memento对象的两个最简单的方法就达到了这个效果。Memento经常写成Originator的内部类。
在Android中，Canvas有两个方法 save()和restore()方法再做图形变换的时候使用的非常多，因为涉及到跨语言的问题，我不好就认定这个用的是备忘录模式，但是它的这种思想绝对是备忘录的思想。

我们来读一读它源代码的注释吧，首先看save()保存状态：

1 2 3 4 5 6 7 8 9 10 11 12 13

public class Canvas {     /**      * Saves the current matrix and clip onto a private stack. Subsequent      * calls to translate,scale,rotate,skew,concat or clip Rect,clipPath      * will all operate as usual, but when the balancing call to restore()      * is made, those calls will be forgotten, and the settings that existed      * before the save() will be reinstated.      */     /**      *保存当前的矩阵和剪裁到一个私有的堆栈，其实矩阵和剪裁就是当前Canvas的状态State      */     public native int save(); }

　　再看恢复状态restore():

1 2 3 4 5 6 7 8 9 10 11

public class Canvas {     /**      * This call balances a previous call to save(), and is used to remove all      * modifications to the matrix/clip state since the last save call. It is      * an error to call restore() more times than save() was called.      */     /**      * 移除自上次保存操作后所做的修改，恢复到之前的状态，因为是堆栈实现，所以pull操作不能不等于push操作，save()和restore()应该成对使用，否则恢复的状态就很有可能是错误的      */     public native void restore(); }

　　从上面的两个方法中，它们实现了自我状态的恢复，实际上我们只是执行了两个没有接触任何内部信息的方法，实际上这两个方法就是在操作我们看不到的这些内部状态信息。

3.效果
(1).保持封装边界，把很复杂的原发器的内部信息对外部其他对象隐藏起来。
(2).简化的原发器，把状态操作无形中转化到客户手里，简化了原发器的某些实现。
(3).也要注意注意备忘录的管理代价。