java编程思想第四版第九章总结

1. 策略设计模式

参考这篇文章：http://blog.csdn.net/chenjie19891104/article/details/6396458 讲的很清楚，策略设计模式。并且举了一个例子，很具有代表性。
先简单了解一下：

　　　　和模板方法模式的区别：

　　　　文章里还有一个例子：

　　　　备注：我来分解，解释一下这个例子。

　　　　将共同的方法定义成了一个接口，在这个接口中并没有这个共同方法的实现。

　　　　在Strategy类中，定义了一个方法execute，它的参数是拥有共同方法的接口类。

　　　　用户Context在调用Strategy的execute方法时，在定义这个共同的方法。这样就大大提高了灵活性。因为公共方法也是可以后定义的。而不是在创建类的时候就定义好了。

　　　　下面把这个例子敲成代码

package net.mindview.interfaces;

//公共方法回调类
interface SameCallback{
    void doTheSame();
}

//定义了一个策略类
interface Strategy {
    void execute(SameCallback sc);
}

//定义策略实现类
class concreteStrategy1 implements Strategy {
    @Override
    public void execute(SameCallback sc) {
        sc.doTheSame();
    }
}

class concreteStrategy2 implements Strategy {
    @Override
    public void execute(SameCallback sc) {
        sc.doTheSame();
    }
}

class concreteStrategy3 implements Strategy {
    @Override
    public void execute(SameCallback sc) {
        sc.doTheSame();
    }
}


public class Context {
    
    public static void main(String[] args) {
        Strategy strategy = new concreteStrategy1();
        //这个公共方法类
        SameCallback sc = new SameCallback() {
            @Override
            public void doTheSame() {
                System.out.println("do same things");
            }
        };
        
        //那个策略需要用到公共方法类,调用即可,如果不用, 那就不在方法中小勇
        strategy.execute(sc);
        
        strategy = new concreteStrategy2();
        strategy.execute(sc);
    }
}

　　　　　　思考：如果一段代码中，总会出现很多的if…else或者case，就要考虑使用策略设计模式了

2. 解耦

看下面这两个例子：

案例一


package net.mindview.interfaces.classprocessor;

import java.math.BigInteger;
import java.util.Arrays;

/**
 * 处理器
 */
class Processor {
    public String name(){
        return getClass().getName();
    };
    //处理
    Object process(Object input) {
        return input;
    }
}

/**
 * 大写处理器
 */
class UpCase extends Processor {
    @Override
    public
    Object process(Object input) {
        return ((String)input).toUpperCase();
    }
}

/**
 * 小写处理器
 */
class DownCase extends Processor {
    @Override
    public
    Object process(Object input) {
        return ((String)input).toLowerCase();
    }
}

/**
 * 分割数组处理器
 */
class Splitter extends Processor {
    @Override
    public
    Object process(Object input) {
        return Arrays.toString(((String)input).toString().split(" "));
    }
}




public class Apply {
    public static void process(Processor p, Object s){
        System.out.println("Using Processor "+ p.name());
        System.out.println(p.process(s));
    }
    
    public static String s = "Disagreement with beliefs is by definition incorrect";
    
    /**
     * 向本例这样, 创建一个能够根据所传递的参数对象的不同而具有不同行为的方法,
     * 被称为策略设计模式
     * @param args
     */
    public static void main(String[] args) {
        BigInteger b = new BigInteger("111111111111111");
        
        process(new UpCase(), s);
        process(new DownCase(), s);
        process(new Splitter(), s);
    }
    
    
    /**
     * 这个类使用到了一个设计模式: 叫做策略设计模式
     * 所谓 的策略设计模式指的是: 能够根据传递参数的不同而具有不同的行为的方法, 被称为策略设计模式
     * 这类方法包含了所有执行的算法中固定不变的部分(这里是基类Processor,Object),而策略就是实际调用该方法时传递的实际参数,
     * 这部分参数是变化的,因此被称之为是"策略"部分.
     * 在main中看到了三种不同类型的策略应用到了String类型s对象上。
     */
}

在这段代码中，定义了一个处理器，这个处理器有两个方法name()和process(). 然后定义了三个类, UpCase, DownCase,Spltter继承自这个类. 当我们在Apply类中定义process(Process process, Object o)方法, 方法传递的参数是父类Process. 这样不仅可以处理父类,还可以处理子类. 在main方法中就有体现. 这就是策略设计模式的思想。但是，他还有局限性。如果在main中想调用Apply.process()方法, 则必须传递Process类或者子类,不能传递其他类。下面这个案例滤波器就说明了这一点：

案例二



package net.mindview.interfaces.filters;

//波形
public class Waveform {
    //计数器,第几波
    private static long counter;
    private final long id = counter ++;
    
    //当前第几波
    @Override
    public String toString() {
        return "Waveform " + id; 
    }
}

package net.mindview.interfaces.filters;

//滤波器
public class Filter {
    public String name(){
        return getClass().getSimpleName();
    }
    //加工
    public Waveform process(Waveform input){
        return input;
    }
}

package net.mindview.interfaces.filters;
/**
 * 低频电磁波
 */
public class LowPass extends Filter{
    //切波的波长
    double cutoff;
    public LowPass(double cutoff){
        this.cutoff = cutoff;
    }
    //加工
    @Override
    public Waveform process(Waveform input) {
        return input;
    }
}

package net.mindview.interfaces.filters;
/**
 * 高频电磁波
 */
public class HighPass extends Filter {
    //切波
    double cutoff;
    public HighPass(double cutoff){
        this.cutoff = cutoff;
    }
    //加工
    @Override
    public Waveform process(Waveform input) {
        return input;
    }
}

package net.mindview.interfaces.filters;
/**
 * 段波电磁波
 */
class BandPass extends Filter {
    //其实切波点, 最高且波点
    double cutoff ,highCutoff;
    public BandPass(double cutoff, double highCutoff){
        this.cutoff = cutoff;
        this.highCutoff = highCutoff;
    }
    //加工
    @Override
    public Waveform process(Waveform input) {
        return input;
    }
}

在上面这个类中，我们定义了一个Filter滤波器。这里面有何Process中同名的两个方法。这个时候，我想复用案例一的Apply类中的process（）方法，可不可以呢？不可以。因为Filter不是Process的子类。虽然， process中的方法体调用完全适用于继承Filter类的子类。为什么不可以呢？Apply就是一个应用类。应用类要处理一些列的类。他可以堆字符串进行处理，应该也可以对波进行处理呀。现在不可以，因为Process类是一个实体类，他和Apply类中的process方法紧密耦合。如果能够实现解耦，那么，就可以将Apply类更加泛化。这就是将Process作为接口来处理

案例三

package net.mindview.interfaces.classprocessor2;

import java.math.BigInteger;
import java.util.Arrays;

/**
 * 处理器
 */
interface Processor {
    public String name();
    //处理
    Object process(Object input);
}

/**
 * 处理器有一部分是所有处理器都是一样的.有一部分是不同的.
 * 所以定义一个抽象类, 将共有方法定义为实体方法, 将各自实现的部分定义为抽象的
 */
abstract class StringProcess implements Processor {
    @Override
    public String name() {
        return getClass().getSimpleName();
    }
    public abstract Object process(Object input);
}


/**
 * 大写处理器
 */
class UpCase extends StringProcess {
    @Override
    public
    Object process(Object input) {
        return ((String)input).toUpperCase();
    }
}

/**
 * 小写处理器
 */
class DownCase extends StringProcess {
    @Override
    public
    Object process(Object input) {
        return ((String)input).toLowerCase();
    }
}

/**
 * 分割数组处理器
 */
class Splitter extends StringProcess {
    @Override
    public
    Object process(Object input) {
        return Arrays.toString(((String)input).toString().split(" "));
    }
}


public class Apply {
    public static void process(Processor p, Object s){
        System.out.println("Using Processor "+ p.name());
        System.out.println(p.process(s));
    }
    
    public static String s = "Disagreement with beliefs is by definition incorrect";
    
    /**
     * 向本例这样, 创建一个能够根据所传递的参数对象的不同而具有不同行为的方法,
     * 被称为策略设计模式
     * @param args
     */
    public static void main(String[] args) {
        BigInteger b = new BigInteger("111111111111111");
        
        process(new UpCase(), s);
        process(new DownCase(), s);
        process(new Splitter(), s);
    }
    
    
    /**
     * 这个类使用到了一个设计模式: 叫做策略设计模式
     * 所谓 的策略设计模式指的是: 能够根据传递参数的不同而具有不同的行为的方法, 被称为策略设计模式
     * 这类方法包含了所有执行的算法中固定不变的部分(这里是基类Processor,Object),而策略就是实际调用该方法时传递的实际参数,
     * 这部分参数是变化的,因此被称之为是"策略"部分.
     * 在main中看到了三种不同类型的策略应用到了String类型s对象上。
     */
}

在这个类里面，将Process定义为了接口。并且添加了StringProcess 字符串处理器类，提供了字符串处理的公用方法。这时如何修改案例二，才能让Apply成为一个公用类呢？其中一个方法是让Filter实现Process接口。但为题又来了，Filter中的process的输入输出参数都是Waveform类型的对象。而Process中process的输入输出都是Object。这时我们使用一个适配器来解决这个问题

package net.mindview.interfaces.filters2;

import net.mindview.interfaces.classprocessor2.Processor;

/**
 * 由于Filter中的process的输入输出参数都是Waveform,而Processor中process的输入
 * 输出参数都是Object. 因此,写一个适配器,让Filter可以适配Processor类型的接口
 * 
 */

public class FilterAdapter implements Processor{
    Filter filter;
    public FilterAdapter(Filter filter){
        this.filter = filter;
    }
    
    @Override
    public String name() {
        return filter.name();
    }

    @Override
    public Object process(Object input) {
        return filter.process((Waveform)input);
    }
}

　　接下来看看Apply类如何处理的？

public class Apply {
    public static void process(Processor p, Object s){
        System.out.println("Using Processor "+ p.name());
        System.out.println(p.process(s));
    }
    
    public static String s = "Disagreement with beliefs is by definition incorrect";
    
    /**
     * 向本例这样, 创建一个能够根据所传递的参数对象的不同而具有不同行为的方法,
     * 被称为策略设计模式
     * @param args
     */
    public static void main(String[] args) {
        System.out.println("======处理字符串===========");
        process(new UpCase(), s);
        process(new DownCase(), s);
        process(new Splitter(), s);
        
        System.out.println("======过滤波===========");
        process(new FilterAdapter(new LowPass(1.0)), new Waveform());
        process(new FilterAdapter(new HighPass(100.0)), new Waveform());
        process(new FilterAdapter(new BandPass(1.0,10.0)), new Waveform());
    }
    
}

　　上面这个例子就示范了使用接口的好处，让类和方法解耦。同时还涉及到一个设计模式，叫适配器设计模式。适配器设计模式有三种, 确切的说这是对象适配器模式.

3. 适配器设计模式

　　参考文章:http://blog.csdn.net/zxt0601/article/details/52848004

　　定义：适配器模式将某个类的接口转换成客户端期望的另一个接口表示，主的目的是兼容性，让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper)。

　　属于结构型模式

　　　　主要分为三类：类适配器模式、对象的适配器模式、接口的适配器模式。

　　本文做以下约定

- 需要被适配的类,对象，接口被定义为源（目前已有的），简称为src(source).
- 最终需要输出的(我们需要的)，简称dst（destination，也叫target）
- 适配器Adapter

　　　　一句话描述适配器模式：src->adapter->dist，即src以某种形式（类，对象，接口）给到适配器，适配器最终输出dist。

　　使用场景

- 想要使用一个已经存在的类，但如果它的方法不满足需求时；
- 两个类的职责相同或相似，但是具有不同的接口时要使用它；
- 应该在双方都不太容易修改的时候再使用适配器模式适配，而不是一有不同时就使用它

　　　第一类: 类适配器模式

　　　　一句话描述使用方法：Adapter类，通过继承src类，实现dist接口，完成src -> dist的适配.

　　　　以充电器为例：充电器本身就是一个适配器。输入的时220v电压，输出的是5v电压。

　　　　首先，有一个src类，本身是输出220v电压　　

package net.mindview.interfaces.adaptor;

/**
 * 这是目前有的电压 200v
 * @author samsung
 *
 */
public class Voltage220 {
    public int output(){
        int i = 220;
        System.out.println("这是220v电压");
        return i;
    }
}

　　　　然后，有一个目标使用电压是5v

package net.mindview.interfaces.adaptor;

/**
 * 我们需要使用的目标电压是5v
 * 这是一个5v电压的接口
 * @author samsung
 *
 */
public interface Voltage5 {
    public int output();
}

　　　　定义一个适配器，将220v电压经过处理后转换为5v电压供用户使用

package net.mindview.interfaces.adaptor;

/**
 * 适配器,将220v电压输出为5v电压
 * 适配器 继承src类, 实现dist类,实现从src->dist的转换
 */
public class VoltageAdapter extends Voltage220 implements Voltage5{
    
    @Override
    public int output() {
        int src = super.output();
        System.out.println("适配器工作开始适配电压");
        int dist = src/44;
        System.out.println("适配完成后输出电压：" + dist);
        return dist;
    }
}

　　　有一款手机需要充电,充电电压是5v

package net.mindview.interfaces.adaptor;

public class Mobile {
    
    public void chargeing(Voltage5 v5){
        if(v5.output() == 5){
            System.out.println("正常充电");
        } else {
            System.out.println("秒变note7");
        }
    }

}

使用手机的时候,需要将家里的220v电压转换为5v输出.调用适配器

public static void main(String[] args) {
        Mobile m = new Mobile();
        m.chargeing(new VoltageAdapter());
    }

输出:

===============类适配器==============
我是220V
适配器工作开始适配电压
适配完成后输出电压：5
电压刚刚好5V，开始充电

小结:

Java这种单继承的机制，所有需要继承的我个人都不太喜欢。
所以类适配器需要继承src类这一点算是一个缺点，
因为这要求dst必须是接口，有一定局限性;
且src类的方法在Adapter中都会暴露出来，也增加了使用的成本。

但同样由于其继承了src类，所以它可以根据需求重写src类的方法，使得Adapter的灵活性增强了。

　　　　第二类: 对象适配器模式

　　　　基本思路和类适配器一样, 只是将adapter类做了修改, 这次不继承src类,而是持有src类实例对象，以解决兼容性问题。

　　　　一句话总结使用方法：持有src类，实现dist类接口，实现src -> dist的适配　　

　　　　(根据”合成复用规则”, 在系统中尽量使用组合来代替继承)

package net.mindview.interfaces.adaptor;
/**
 * 持有src类，实现dist类接口， 实现src -> dist的适配
 * @author samsung
 *
 */
public class VoltageAdapter2 implements Voltage5{
    Voltage220 voltage220;
    
    public VoltageAdapter2(Voltage220 voltage220){
        this.voltage220 = voltage220;
    }
    
    @Override
    public int output() {
        System.out.println("得到220v电压");
        int src = voltage220.output();
        System.out.println("经过处理,输出5v电压");
        int dist = src/44;
        System.out.println("最终使用的电压是"+dist+"v");
        return dist;
    }
}

测试结果:

得到220v电压
这是220v电压
经过处理,输出5v电压
最终使用的电压是5v
正常充电

小结:

对象适配器和类适配器其实算是同一种思想，只不过实现方式不同。
根据合成复用原则，组合大于继承，
所以它解决了类适配器必须继承src的局限性问题，也不再强求dst必须是接口。
同样的它使用成本更低，更灵活。

　　第三类接口适配器模式

也有文献称之为认适配器模式(Default Adapter Pattern)或缺省适配器模式。
定义：
　　当不需要全部实现接口提供的方法时，可先设计一个抽象类实现接口，并为该接口中每个方法提供一个默认实现（空方法），那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求，它适用于一个接口不想使用其所有的方法的情况。

我们直接进入大家最喜爱的源码撑腰环节：

源码撑腰环节：

Android中的属性动画ValueAnimator类可以通过addListener(AnimatorListener listener)方法添加监听器，
那么常规写法如下：

 ValueAnimator valueAnimator = ValueAnimator.ofInt(0,100);
        valueAnimator.addListener(new Animator.AnimatorListener() {
            @Override
            public void onAnimationStart(Animator animation) {

            }

            @Override
            public void onAnimationEnd(Animator animation) {

            }

            @Override
            public void onAnimationCancel(Animator animation) {

            }

            @Override
            public void onAnimationRepeat(Animator animation) {

            }
        });
        valueAnimator.start();

有时候我们不想实现Animator.AnimatorListener接口的全部方法，我们只想监听onAnimationStart，我们会如下写：

 ValueAnimator valueAnimator = ValueAnimator.ofInt(0,100);
        valueAnimator.addListener(new AnimatorListenerAdapter() {
            @Override
            public void onAnimationStart(Animator animation) {
                //xxxx具体实现
            }
        });
        valueAnimator.start();

显然，这个AnimatorListenerAdapter类，就是一个接口适配器。
查看该Adapter类源码：

public abstract class AnimatorListenerAdapter implements Animator.AnimatorListener,
        Animator.AnimatorPauseListener {
    @Override
    public void onAnimationCancel(Animator animation) {
    }

    @Override
    public void onAnimationEnd(Animator animation) {
    }

    @Override
    public void onAnimationRepeat(Animator animation) {
    }

    @Override
    public void onAnimationStart(Animator animation) {
    }

    @Override
    public void onAnimationPause(Animator animation) {
    }

    @Override
    public void onAnimationResume(Animator animation) {
    }
}

可见，它空实现了Animator.AnimatorListener类(src)的所有方法.
对应的src类：

 public static interface AnimatorListener {
        void onAnimationStart(Animator animation);

        void onAnimationEnd(Animator animation);

        void onAnimationCancel(Animator animation);

        void onAnimationRepeat(Animator animation);
    }

类图：

这里写图片描述
我们程序里的匿名内部类就是Listener1 2 这种具体实现类。

 new AnimatorListenerAdapter() {
            @Override
            public void onAnimationStart(Animator animation) {
                //xxxx具体实现
            }
        }

接口适配器模式很好理解，令我们的程序更加简洁明了。

总结

我个人理解，三种命名方式，是根据 src是以怎样的形式给到Adapter（在Adapter里的形式）来命名的。
类适配器，以类给到，在Adapter里，就是将src当做类，继承，
对象适配器，以对象给到，在Adapter里，将src作为一个对象，持有。
接口适配器，以接口给到，在Adapter里，将src作为一个接口，实现。

Adapter模式最大的作用还是将原本不兼容的接口融合在一起工作。
但是在实际开发中，实现起来不拘泥于本文介绍的三种经典形式，
例如Android中ListView、GridView的适配器Adapter，就不是以上三种经典形式之一，
我个人理解其属于对象适配器模式，一般日常使用中，我们都是在Adapter里持有datas，然后通过getView()/onCreateViewHolder()方法向ListView/RecyclerView提供View/ViewHolder。

Client是Lv Gv Rv ，它们是显示View的类。
所以dst(Target)是View。
一般来说我们有的src是数据datas，
即，我们希望：datas（src）->Adapter->View(dst)->Rv(Client)。

本文链接：https://www.cnblogs.com/ITPower/p/8550627.html

java编程思想第四版第九章总结

小结:

小结:

源码撑腰环节：

总结

java编程思想第四版第九章总结的更多相关文章

随机推荐

热门专题

目录导航