Android设计模式------组件协作模式

组件协作模式通过晚期绑定，来实现框架与应用程序直接的松耦合，是二者之间协作时常用的模式。

典型模式

Template Method 模板方法

Strategy 策略模式

Observer / Event 观察者模式

 

 

Template Method 模板方法

在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。

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

主要解决：一些方法通用，却在每一个子类都重新写了这一方法。

何时使用：有一些通用的方法。

如何解决：将这些通用算法抽象出来。

关键代码：在抽象类实现，其他步骤在子类实现。

应用实例： 1、在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。 2、西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。 3、spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务、获取 Session、关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。

优点： 1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。

缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。

使用场景： 1、有多个子类共有的方法，且逻辑相同。 2、重要的、复杂的方法，可以考虑作为模板方法。

注意事项：为防止恶意操作，一般模板方法都加上 final 关键词。

解决的场景是 

在软件构建过程中，对于某一项任务， 它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因(比如框架与应用之间的关系)而无法和任务的整体结构同时实现。

 模式定义 

定义一个操作中的算法的骨架（稳定），而将一些步骤延迟（变化）到子类中。Template Method使子类可以不改变（复用）一个算法的结构即可重定义（override 重写）该算法的某些特定步骤。 

类图结构

图中AbstractClass和PrimitiveOperation1()和PrimitiveOperation2()是稳定的。

ConcreteClass是变化的

代码举例

程序库开发人员要开发一个Libray，责任是做step1(),step3(),step5()

第一种开发方式：

//程序库开发人员
class Library {

    //类库开发的代码也是稳定的，一般不会做改变
    public void step1() {
        //...
    }

    //稳定
    public void step3() {
        //...
    }

    //稳定
    public void step5() {
        //...
    }

}

而应用程序开发人员 需要做step2(),step4()。 并且把这些步骤打包在一起。

//应用程序开发人员
class Application {

    //而 step()中的内容可能发生变化
    public boolean step2() {
        //...
        return true;
    }

    //变化
    public void step4() {
        //...
    }

    // 下面部分代码是比较稳定的  步骤都是一样的
    public static void main(String args[]) {


        Library lib = new Library();

        Application app = new Application();

        lib.step1();

        if (app.step2()) {
            lib.step3();
        }

        for (int i = 0; i < 4; i++) {
            app.step4();
        }

        lib.step5();
    }

}

以上的设计方式不够好。

作为程序库开发人员，应该写更多方面的代码，将稳定不变的代码放入类库代码中。比如上面的Main()中的步骤代码。设计成一个函数。方法内容可能发生变化的方法，尽量写成抽象函数。

第二种开发方式：

//程序库开发人员
abstract class Library {
    public void run() {//稳定 template method 模块方法

        step1();
        if (step2()) {//支持变化 ==> 普通函数的多态调用
            step3();
        }

        for (int i = 0; i < 4; i++) {
            step4();//支持变化 ==> 普通函数的多态调用
        }

        step5();
    }


    protected void step1() {//稳定
        //...
    }

    protected void step3() {//稳定
        //...
    }

    protected void step5() {//稳定
        //...
    }

    abstract boolean step2();//变化

    abstract void step4();//变化
}

而应用开发人员可以减少代码量,只需要写出继承父类中的抽象方法。比如对step2(),step4()进行重写。

//应用程序开发人员
class Application extends Library {

    @Override
    protected boolean step2() {
        //... 子类重写实现
        return true;
    }

    @Override
    protected void step4() {
        //... 子类重写实现
    }

    public static void main(String args[]) {

        Library lib = new Application(); //多态表现
        lib.Run();

    }

}

 第二种开发方式相对于第一种开发方式，很明显应用程序开发人员写的代码变少了，这表明了复用性得到了提升。以后的类继承Library都可以直接复用step1(),step3(),step5(),run()。

 

结构化软件设计流程

 Application开发人员，程序主流程应该交给Library做，因为它是不需要变化的，是稳定的。

面向对象软件设计流程

 红色步骤模块是稳定的，蓝色步骤模块是变化的。

早绑定与晚绑定

Android代码举例  

在Android代码也使用了模板方法。在AppCompatActivity类中 onCreate(),onStart(),onStop(),onDestroy()就类似上面的step1(), step2(), step3(), step4(),step5() 。

要点总结

     Template Method模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构。 

    除了可以灵活应对子步骤的变化外，“不要调用我，让我来调用你”的反向控制结构是Template Method的典型应用。 

    在具体实现方面，被Template Method调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为protected方法。
 

 

 

Strategy 策略模式

在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。

在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。

意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。

主要解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。

何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。

如何解决：将这些算法封装成一个一个的类，任意地替换。

关键代码：实现同一个接口。

应用实例： 1、诸葛亮的锦囊妙计，每一个锦囊就是一个策略。 2、旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。 3、JAVA AWT 中的 LayoutManager。

优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。

缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。

使用场景： 1、如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。 2、一个系统需要动态地在几种算法中选择一种。 3、如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。

注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。

解决问题

 在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。

模式定义 

定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可以独立于使用它的客户程序（稳定）而变化（扩展，子类化）。 

 

类图结构

Context和Strategy是稳定的。ConcreteStrategyA,B,C都是具体的算法，它们是变化的，子类化。

假设设计一个订单系统，有一个计算税务需求。

先是开发 CN_Tax,US_Tax,DE_Tax 三种计算税务的方式。

下面代码在设计上有缺点，比如系统想部署在FR地区，并且和其他税务计算方式不一样。这时候需要在枚举类型TaxBase 中 添加FR_Tax。并且在calculateTax()中添加case FR_Tax: 。这样的设计方法违背了开闭原则----对扩展开发，对更改关闭。类模块发生需求改变的时候，尽量不要修改代码，应该用增加拓展的方式对需求进行修改。

如果只在一个地区部署该系统，比如在CN地区部署，只使用了CN_Tax计算税务方式，在calculateTax()中只运行case CN_Tax。

而其他case 并不会被执行到。但是其他case 代码都会被加载到内存中，并且还会被Git编译，要装置到CPU缓存里面。 

public enum TaxBase {
    CN_Tax,
    US_Tax,
    DE_Tax,
    FR_Tax, //更改
};

public class SalesOrder{

    TaxBase tax;

    public void calculateTax(){

        //...

        switch(tax){
            case CN_Tax:
                //CN***********
                break;
            case US_Tax:
                //US***********
                break;
            case De_Tax:
                //DE***********
                break;
            case FR_Tax:  //更改
                //FR***********
                break
        }


        //....
    }

}

使用策略模式思想 重构上面代码

abstract class TaxStrategy{
    public abstract double Calculate(Context context);
}

public class CNTax extends TaxStrategy{

    @Override
    public double Calculate(Context context){
        //......
    }

}

public class USTax extends TaxStrategy{

    @Override
    public  double Calculate(Context context){
        //******
    }
}

public class DETax extends TaxStrategy{

    @Override
    public  double Calculate(Context context){
        //######
    }
}

//扩展
public class FRTax extends TaxStrategy{

    @Override
    public  double Calculate(Context context){
        //######
    }
}



public class SalesOrder{

    TaxStrategy strategy;

    public SalesOrder(TaxStrategy strategy){
        this.strategy=strategy;
    }


    public double CalculateTax(){
        //...
        Context context;

        double val=strategy.Calculate(context);//多态调用
        //...

    }

}

如果只部署到CN地区，运行时就只会加载CNTax类，其他的类都不会被加载到内存中，也就不会被装载到CPU高级缓存中。

Java中策略模式体现

在java标准库中，对数组排序使用sort()。数值是有大小之分的，但是对类进行排序，需要自己提供判断大小的策略。

在上面代码中Comparator就是一个算法策略。public interface Comparator<T>。接口和抽象类在java里边意义是非常接近的。

需要对某种类型进行排序，需要先定义类型排序的策略，也就是Comparator，而不是写死。

要点总结 

  Strategy及其子类为组件提供了一系列可重用的算法，从而使得类型在运行时方便地根据需要在各个算法之间进行切换。 

  Strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。

 
  如果Strategy对象没有实例变量，那么各个上下文可以共享同一个Strategy对象，从而节省对象开销。

 

当写代码碰到枚举类型，switch语句，if-else语句，想想是否可以使用Strategy重构代码。

 

Observer/Event  观察者模式

当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知它的依赖对象。观察者模式属于行为型模式。

意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。

何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。

如何解决：使用面向对象技术，可以将这种依赖关系弱化。

关键代码：在抽象类里有一个 ArrayList 存放观察者们。

应用实例： 1、拍卖的时候，拍卖师观察最高标价，然后通知给其他竞价者竞价。 2、西游记里面悟空请求菩萨降服红孩儿，菩萨洒了一地水招来一个老乌龟，这个乌龟就是观察者，他观察菩萨洒水这个动作。

优点： 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。

缺点： 1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。

使用场景：

• 一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。
• 一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，可以降低对象之间的耦合度。
• 一个对象必须通知其他对象，而并不知道这些对象是谁。
• 需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。

注意事项： 1、JAVA 中已经有了对观察者模式的支持类。 2、避免循环引用。 3、如果顺序执行，某一观察者错误会导致系统卡壳，一般采用异步方式。

解决问题场景

在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。

使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。

模式定义 

定义对象间的一种一对多（变化）的依赖关系，以便当一个对象（Subject）的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。 

类图结构

代码举例

当EditText内容发生变化的时候，将内容长度显示在TextView当中。对EditText做一个观察者，当里面内容发生改变的时候都可以捕获到。

public class MainActivity extends AppCompatActivity {

    private Button mAppendButton;
    private EditText mEditText;
    private TextView mLabelText;

    private int count=0;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);


        mAppendButton = (Button) findViewById(R.id.appendButton);
        mEditText = (EditText) findViewById(R.id.contentEdit);
        mLabelText = (TextView) findViewById(R.id.countText);


        //订阅通知
        mEditText.addTextChangedListener(textWatcher);

        //取消订阅
        //mEditText.removeTextChangedListener(textWatcher);

        mAppendButton.setOnClickListener(clickListener);


    }


    OnClickListener clickListener = new OnClickListener() {
        @Override
        public void onClick(View v) {
            String content = mEditText.getText().toString().trim();
            //文本框内容处理
            content = content + Integer.toString(count);
            count++;
            mEditText.setText(content);
            mEditText.setSelection(content.length());//光标置于末尾
        }
    };


    TextWatcher textWatcher = new TextWatcher() {

        public void beforeTextChanged(CharSequence s, int start, int count, int after) {

            Log.i("BeforeTextChanged:", s.toString() );
        }


        public void onTextChanged(CharSequence s, int start, int before, int count) {

            Log.i("OnTextChanged:", s.toString() );
        }

        public void afterTextChanged(Editable s) {
            String count = Integer.toString(s.length());
            mLabelText.setText(count);
        }
    };

}

实时获取EditText内容长度

 

类图结构中的 Observer对应以上代码的TextWatcher。ConcreteSubject对应的是EditText。在Subject中Attach(observer) 添加观察者 对应的是addTextChangedListener()。Detach(Observer)对应的是removeTextChangedListener()。Notify()对应的是sendAfterTextChanged()。Notify()作用是通知所有的观察者。ConcreteObserver对应的是textWatcher实现了三个Update(),beforeTextChanged(),onTextChanged(),afterTextChanged()。

Subject和Observer是稳定的部分。ConcreteSubject和ConcreteObserver是子类都是变化的。

 

要点总结 

- 增加的Listener会组成一个ArrayList,每当目标对象状态发生改变，则遍历ArrayList通知所有观察者。 
- 使用面向对象的抽象，Observer模式使我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合。 
- 目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。 
- 观察者自己决定是否需要订阅通知，目标对象对此一无所知。 
- Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。