从实际例子出发讲解面向组合子编程

前言

一直以来想要表述下,在这几年的时间里面对 OO(面向对象) 和 CO(面向组合子编程) 的理解,终于在闲暇时间里,可以好好阐述下这个思想。

关于 OO(面向对象) 和 CO(面向组合子编程) 的理解,有一个很有意思的描述:

OO:白马是白色的马。 CO:白马非马,是由「白」和「马」组成的。

这个理解在一定程度上是正确的,但是更像是面向组件编程,而离「面向组合子编程」还是有一定的差距。面向组件更像是对「组合与继承」的一种反思,组合子编程则更类似于 「编写一门领域语言」。在接下来的章节里面,我们将为什么要「善用组合」,然后如何将思维进阶到「组合子编程」里面来。

善用组合

我们从实际的例子出发,来说明下组合的好处。设想我们需要开发一个 Android App 用来实现一个绘制图形的 App .刚开始 PM 提出了需求,这个 App 需要支持绘制红色的线条,和蓝色的线条,接到这个需求后,作为学过 OO 的小明,当即做出了用继承来实现这个需求的架构,简单的代码实现如下:


public class Line {
	public abstract void draw() {
		// draw line.
	}
}

public class RedLine extends Line {
	public void draw() {
		// draw line.
		// print red color.
	}
}

public class BuleLine extends Line {
	public void draw() {
		// draw line.
		// print blue color.
	}
}

这个 App 成功地上线后,用户广泛地好评,PM 的野心又出现了,既然可以画线,那么也可以画方块。 PM 又提出了一个需求, 需要实现对绘制红色方块和蓝色方块的需求。小明想了一下后,在原有的基础上再继承一下,就可以了吧。于是 AppV2 的代码就诞生了:


public class Rect {
	public abstract void draw() {
		// draw Rect.
	}
}

public class RedRect extends Rect {
	public void draw() {
		// draw Rect.
		// print red color.
	}
}

public class BuleRect extends Rect {
	public void draw() {
		// draw Rect.
		// print blue color.
	}
}

这样一共有6个类文件了,小明心想这PM该满足了吧。 在App上线一段时间后,用户觉得体验太好了,又提出了新的反馈,需要加入其他画笔。这个时候 PM 又提出了其他的需求了, 比如绿色的圆,黄色的五角星等等。 小明这下爆炸了, 原有的实现里面完全没法满足后续的需求了,整个项目充斥着类的爆炸,复用程度低下。那么如何来解决这些问题了?答案就是「善用组合」。


public interface Drawable {
	void draw();
}

public class Shape implements Drawable {
	public Shape(String type) {

	}

	public void draw() {
		// draw according to type.
	}
}

public class Color implements Drawable {
	public Color(int rgba) {

	}

	public void draw() {
		// draw color by rgba.
	}
}

public class Paint {
	public static void drawRedRect() {
		Shape rect = new Shape(ShapeType.Rect);
		Color red = new Color("#FF231424");
		canvas.draw(rect, red);
	}
}

这样实现后,复用性得以提升,逻辑也更加清晰,在下面的章节里面,我们再来思考如何用组合子的方式来考虑这个问题。

组合子的思考方式

再次回到这个例子里面,我们再次回到这个需求里面来,需要实现的是一系列的绘图操作。这个 App 里面,我们可以简单地分为几个模块,Color, Shape, Operation; 这几个模块通过组合的方式,就可以用复用度良好的方式来完成整个 App 了。按理说,如果我们采用组合的方式已经能够实现很好的鲁棒性和复用性了,那么还欠缺一些什么了?欠缺一些更加高阶的抽象!

我们的思路往往都是从自顶向下地来进行,先有了要做什么事情,然后再把事情做拆分,最后拆分成可执行的颗粒度足够细化的模块。这种思考方式在 OO 时代就被广泛采用,做出的项目设计方案也往往能够拥有不错的复用性和扩展性。而组合子编程思考的角度是自底向上的,这样考虑的方式会给我们另一种途径来解读项目设计。(PS 自顶向下是一种很好的方式,应该推崇)

当使用组合子编程的时候,我们考虑更多的是从底部出发,水到渠成地满足了需求,当需求变化的时候,也能很快地得以支持。回到前面这个 绘图 App 的例子里面来, 对于绘图这件事情,我们是有什么元操作呢? 我们需要如何简单地构建基础工具了,如何把设计好的组件的方式用一致的方式拼接起来?这里会有一些 DSL 的意思在里面。

我们来看看如何定义最基础的逻辑,一定是一个最基础的抽象,设想就是一个 Drawable 抽象。

public interface Drawable {
	public void draw(Canvas canvs) {
	}
}

那么我们现在是不是可以写 Pen,Color 这些抽象了呢?其实不用急,我们得让一起可以运作起来。我们来构建一个序列化执行的Drawable, 有了这个SerialDrawable,我们就可以支持起顺序架构这个关键功能了。比如我们可以实现前面提及的 RedRect, BlueLine 等等。

public class SerialDrawable implements Drawable {

	private List<Drawable> drawbles = new ArrayList<>();

	public void draw(Canvas canvas) {
		for (Drawable drawable : drawables) {
			drawable.draw(canvas);
		}
	}

	public void appendDrawable(Drawable drawable) {
		drawables.add(drawable);
	}
}

另外同样我们可以实现 NonDrawable 来表示空, FilterDrawable 来便是可过滤的Drawable. 通过这些原子的数据,我们就可以架构出整个世界了。(PS to be continued …)

更多内容请参考 ajooo-名著类

Android 源码中的设计模式

最近看了一些android的源码,发现设计模式无处不在啊!感觉有点乱,于是决定要把设计模式好好梳理一下,于是有了这篇文章。

1. Singleton(单例模式)

作用:

保证在Java应用程序中,一个类Class只有一个实例存在。

好处:

由于单例模式在内存中只有一个实例,减少了内存开销。

单例模式可以避免对资源的多重占用,例如一个写文件时,由于只有一个实例存在内存中,避免对同一个资源文件的同时写操作。

单例模式可以再系统设置全局的访问点,优化和共享资源访问。

使用情况:

建立目录 数据库连接的单线程操作

某个需要被频繁访问的实例对象

1.1 使用方法

第一种形式:

public class Singleton {

    /* 持有私有静态实例,防止被引用,此处赋值为null,目的是实现延迟加载 */
    private static Singleton instance = null;

    /* 私有构造方法,防止被实例化 */
    private Singleton() {
    }

    /* 懒汉式:第一次调用时初始Singleton,以后就不用再生成了 静态方法,创建实例 */
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

但是这有一个问题,不同步啊!在对据库对象进行的频繁读写操作时,不同步问题就大了。

第二种形式

既然不同步那就给getInstance方法加个锁呗!我们知道使用synchronized关键字可以同步方法和同步代码块,所以:

 public static synchronized Singleton getInstance() {  
     if (instance == null) {  
         instance = new Singleton();  
     }  
     return instance;  
 } 

或是

public static Singleton getInstance() {  
     synchronized (Singleton.class) {  
         if (instance == null) {  
             instance = new Singleton();  
         }  
     }  
     return instance;  
 } 

获取Singleton实例:

Singleton.getInstance().方法()

1.2android中的Singleton

软键盘管理的 InputMethodManager

源码(以下的源码都是5.1的):

205 public final class InputMethodManager {
//.........
211     static InputMethodManager sInstance;
//.........
619     public static InputMethodManager getInstance() {
620         synchronized (InputMethodManager.class) {
621             if (sInstance == null) {
622                 IBinder b = ServiceManager.getService(Context.INPUT_METHOD_SERVICE);
623                 IInputMethodManager service = IInputMethodManager.Stub.asInterface(b);
624                 sInstance = new InputMethodManager(service, Looper.getMainLooper());
625             }
626             return sInstance;
627         }
628     }

使用的是第二种同步代码块的单例模式(可能涉及到多线程),类似的还有
AccessibilityManager(View获得点击、焦点、文字改变等事件的分发管理,对整个系统的调试、问题定位等)
BluetoothOppManager等。

当然也有同步方法的单例实现,比如:CalendarDatabaseHelper

307     public static synchronized CalendarDatabaseHelper getInstance(Context context) {
308         if (sSingleton == null) {
309             sSingleton = new CalendarDatabaseHelper(context);
310         }
311         return sSingleton;
312     }

2. Factory(工厂模式)

 定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
对同一个接口的实现类进行管理和实例化创建

这里写图片描述

假设我们有这样一个需求:

动物Animal,它有行为move()。有两个实现类cat和dog。为了统一管理和创建我们设计一个工厂模式。
同时两个子类有各自的行为,Cat有eatFish(),Dog有eatBone().

结构图:
这里写图片描述

Animal接口:

interface animal {
    void move();
}

Cat类:

public class Cat implements Animal{

    @Override
    public void move() {
        // TODO Auto-generated method stub
        System.out.println("我是只肥猫,不爱动");
    }
    public void eatFish() {  
        System.out.println("爱吃鱼");
    } 
}

Dog类:

public class Dog implements Animal{

    @Override
    public void move() {
        // TODO Auto-generated method stub
        System.out.println("我是狗,跑的快");
    }
    public void eatBone() {  
        System.out.println("爱吃骨头");
    } 
}

那么现在就可以建一个工厂类(Factory.java)来对实例类进行管理和创建了.

public class Factory {
    //静态工厂方法
    //多处调用,不需要实例工厂类 
     public static Cat produceCat() {  
            return new Cat();  
        } 
     public static Dog produceDog() {  
            return new Dog();  
        }
//当然也可以一个方法,通过传入参数,switch实现
}

使用:

Animal cat = Factory.produceCat();
cat.move();
//-----------------------------
Dog dog = Factory.produceDog();
dog.move();
dog.eatBone();

工厂模式在业界运用十分广泛,如果都用new来生成对象,随着项目的扩展,animal还可以生出许多其他儿子来,当然儿子还有儿子,同时也避免不了对以前代码的修改(比如加入后来生出儿子的实例),怎么管理,想着就是一团糟。

Animal cat = Factory.produceCat();

这里实例化了Animal但不涉及到Animal的具体子类(减少了它们之间的偶合联系性),达到封装效果,也就减少错误修改的机会。

Java面向对象的原则,封装(Encapsulation)和分派(Delegation)告诉我们:具体事情做得越多,越容易范错误,

一般来说,这样的普通工厂就可以满足基本需求。但是我们如果要新增一个Animal的实现类panda,那么必然要在工厂类里新增了一个生产panda的方法。就违背了 闭包的设计原则(对扩展要开放对修改要关闭) ,于是有了抽象工厂模式。

2.1 Abstract Factory(抽象工厂)

抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
啥意思?就是把生产抽象成一个接口,每个实例类都对应一个工厂类(普通工厂只有一个工厂类),同时所有工厂类都继承这个生产接口

生产接口Provider:

interface Provider {
    Animal produce(); 
}

每个产品都有自己的工厂
CatFactory:

public class CatFactory implements Provider{

    @Override
    public Animal produce() {
        // TODO Auto-generated method stub
        return new Cat();
    }
}

DogFactory:

public class DogFactory implements Provider{

    @Override
    public Animal produce() {
        // TODO Auto-generated method stub
        return new Dog();
    }
}

产品生产:

Provider provider = new CatFactory();
Animal cat =provider.produce();
cat.move();

现在我们要加入panda,直接新建一个pandaFactory就行了,这样我们系统就非常灵活,具备了动态扩展功能。

2.1 Android中的Factory

比如AsyncTask的抽象工厂实现:

工厂的抽象:

59 public interface ThreadFactory {
//省略为备注
69    Thread newThread(Runnable r);
70 }

产品的抽象(new Runnable就是其实现类):

56   public interface Runnable {
//省略为备注
68    public abstract void run();
69 }

AsyncTask中工厂类的实现:

185    private static final ThreadFactory sThreadFactory = new ThreadFactory() {
186        private final AtomicInteger mCount = new AtomicInteger(1);
187
188        public Thread newThread(Runnable r) {
189            return new Thread(r, "AsyncTask #" + mCount.getAndIncrement());
190        }
191    };

我们可以创建另外类似的工厂,生产某种专门的线程(多线程),非常容易扩展。
当然,android中的应用还有很多(比如BitmapFactory),有兴趣的小伙伴可以去扒一扒。

3. Adapter(适配器模式)

将一个类的接口转换成客户希望的另外一个接口

我们经常碰到要将两个没有关系的类组合在一起使用,第一解决方案是:修改各自类的接口,但是如果我们没有源代码,或者,我们不愿意为了一个应用而修改各自的接口。 怎么办?

使用Adapter,在这两种接口之间创建一个混合接口。

模式中的角色

需要适配的类(Adaptee):需要适配的类。

适配器(Adapter):通过包装一个需要适配的对象,把原接口转换成目标接口。

目标接口(Target):客户所期待的接口。可以是具体的或抽象的类,也可以是接口。

这里写图片描述

// 需要适配的类 
class Adaptee {  
    public void specificRequest() {  
        System.out.println("需要适配的类");  
    }  
}  

// 目标接口 
interface Target {  
    public void request();  
} 

实现方式:

①、对象适配器(采用对象组合方式实现)

// 适配器类实现标准接口
class Adapter implements Target{
    // 直接关联被适配类
    private Adaptee adaptee;

    // 可以通过构造函数传入具体需要适配的被适配类对象
    public Adapter (Adaptee adaptee) {
        this.adaptee = adaptee;
    }

    public void request() {
        // 这里是使用委托的方式完成特殊功能
        this.adaptee.specificRequest();
    }
}

// 测试类
public class Client {
    public static void main(String[] args) {
        // 需要先创建一个被适配类的对象作为参数
        Target adapter = new Adapter(new Adaptee());
        adapter.request();
    }
}

如果Target不是接口而是一个具体的类的情况,这里的Adapter直接继承Target就可以了。

②、类的适配器模式(采用继承实现)

// 适配器类继承了被适配类同时实现标准接口 
class Adapter extends Adaptee implements Target{  
    public void request() {  
        super.specificRequest();  
    }  
}  

// 测试类
    public static void main(String[] args) {              
        // 使用适配类 
        Target adapter = new Adapter();  
        adapter.request();  
    } 

如果Target和 Adaptee都是接口,并且都有实现类。 可以通过Adapter实现两个接口来完成适配。
还有一种叫PluggableAdapters,可以动态的获取几个adapters中一个。使用Reflection技术,可以动态的发现类中的Public方法。

优点

系统需要使用现有的类,而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用
将目标类和适配者类解耦,通过引入一个适配器类重用现有的适配者类,而无需修改原有代码,更好的扩展性

缺点

过多的使用适配器,会让系统非常零乱,不易整体进行把握。比如,明明看到调用的是A接口,其实内部被适配成了B接口的实现。如果不是必要,不要使用适配器,而是直接对系统进行重构。

3.1 Android中的Adapter

android中的Adapter就有很多了,这个大家都经常用。
Adapter是AdapterView视图与数据之间的桥梁,Adapter提供对数据的访问,也负责为每一项数据产生一个对应的View。

Adapter的继承结构

这里写图片描述

BaseAdapter的部分源码:

30public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter {
31    private final DataSetObservable mDataSetObservable = new DataSetObservable();
32
33    public boolean hasStableIds() {
34        return false;
35    }
36    
37    public void registerDataSetObserver(DataSetObserver observer) {
38        mDataSetObservable.registerObserver(observer);
39    }
40
41    public void unregisterDataSetObserver(DataSetObserver observer) {
42        mDataSetObservable.unregisterObserver(observer);
43    }

ListAdapter, SpinnerAdapter都是Target ,数据是Adaptee ,采用对象组合方式。

4. Chain of Responsibility(责任链模式)

使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。

发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。

编程中的小体现:

if(a<10){
    ...
}
else if (a<20){
    ...
}
else if(a<30){
    ...
}
else{
    ...
}

程序必须依次扫描每个分支进行判断,找到对应的分支进行处理。

责任链模式的优点

可以降低系统的耦合度(请求者与处理者代码分离),简化对象的相互连接,同时增强给对象指派职责的灵活性,增加新的请求处理类也很方便;

责任链模式的缺点

不能保证请求一定被接收,且对于比较长的职责链,请求的处理可能涉及到多个处理对象,系统性能将受到一定影响,而且在进行代码调试时不太方便。
每次都是从链头开始,这也正是链表的缺点。

4.1 Android中的Chain of Responsibility

触摸、按键等各种事件的传递

这里写图片描述

有兴趣的可以看一下这篇文章View事件分发机制源码分析,我这就不多说了。

5. Observer(观察者模式)

有时被称作发布/订阅模式,观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使它们能够自动更新自己。

将一个系统分割成一个一些类相互协作的类有一个不好的副作用,那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合,这样会给维护、扩展和重用都带来不便。观察者就是解决这类的耦合关系的(依赖关系并未完全解除,抽象通知者依旧依赖抽象的观察者。)。

观察者模式的组成

①抽象主题(Subject)

它把所有观察者对象的引用保存到一个聚集里,每个主题都可以有任何数量的观察者。抽象主题提供一个接口,可以增加和删除观察者对象。

②具体主题(ConcreteSubject)

将有关状态存入具体观察者对象;在具体主题内部状态改变时,给所有登记过的观察者发出通知。

③抽象观察者(Observer)

为所有的具体观察者定义一个接口,在得到主题通知时更新自己。

④具体观察者(ConcreteObserver)

实现抽象观察者角色所要求的更新接口,以便使本身的状态与主题状态协调。

这里写图片描述

言语苍白,上代码:

//抽象观察者
public interface Observer
{
  public void update(String str);

}
//具体观察者
public class ConcreteObserver implements Observer{
    @Override
    public void update(String str) {
        // TODO Auto-generated method stub
        System.out.println(str);
    }
}
//抽象主题
public interface Subject
{
    public void addObserver(Observer observer);
    public void removeObserver(Observer observer);
    public void notifyObservers(String str);
}
//具体主题
public class ConcreteSubject implements Subject{
    // 存放观察者
    private List<Observer> list = new ArrayList<Observer>();
    @Override
    public void addObserver(Observer observer) {
        // TODO Auto-generated method stub
        list.add(observer);
    }

    @Override
    public void removeObserver(Observer observer) {
        // TODO Auto-generated method stub
        list.remove(observer);
    }

    @Override
    public void notifyObservers(String str) {
        // TODO Auto-generated method stub
        for(Observer observer:list){
            observer.update(str);
        }
    }
}

下面是测试类:

/** * @author fanrunqi */
public class Test {
     public static void main(String[] args) {
        //一个主题
         ConcreteSubject eatSubject = new ConcreteSubject();
         //两个观察者
         ConcreteObserver personOne = new ConcreteObserver();
         ConcreteObserver personTwo = new ConcreteObserver();
         //观察者订阅主题
         eatSubject.addObserver(personOne);
         eatSubject.addObserver(personTwo);

         //通知开饭了
         eatSubject.notifyObservers("开饭啦");
    }
}

“关于代码你有什么想说的?”
“没有,都在代码里了”
“(⊙o⊙)哦.....”

5.1 Android中的Observer

观察者模式在android中运用的也比较多,最熟悉的ContentObserver。

① 抽象类ContentResolver中(Subject)

注册观察者:

1567    public final void registerContentObserver(Uri uri, boolean notifyForDescendents,
1568            ContentObserver observer, int userHandle)

取消观察者:

1583    public final void unregisterContentObserver(ContentObserver observer) 

抽象类ContentObserver中(Observer)

94     public void onChange(boolean selfChange) {
95         // Do nothing. Subclass should override.
96     }

144    public void onChange(boolean selfChange, Uri uri, int userId) {
145        onChange(selfChange, uri);
146    }

129    public void onChange(boolean selfChange, Uri uri) {
130        onChange(selfChange);
131    }

观察特定Uri引起的数据库的变化,继而做一些相应的处理(最终都调用的第一个函数).

② DataSetObserver,其实这个我们一直在用,只是没意识到。

我们再看到BaseAdapter的部分源码:

37    public void registerDataSetObserver(DataSetObserver observer) {
38        mDataSetObservable.registerObserver(observer);
39    }
40
41    public void unregisterDataSetObserver(DataSetObserver observer) {
42        mDataSetObservable.unregisterObserver(observer);
43    }

上面两个方法分别向向BaseAdater注册、注销一个DataSetObserver实例。

DataSetObserver 的源码:

24 public abstract class DataSetObserver {

29    public void onChanged() {
30        // Do nothing
31    }

38    public void onInvalidated() {
39        // Do nothing
40    }
41}

DataSetObserver就是一个观察者,它一旦发现BaseAdapter内部数据有变量,就会通过回调方法DataSetObserver.onChanged和DataSetObserver.onInvalidated来通知DataSetObserver的实现类。

6. Builder(建造者模式)

建造者模式:是将一个复杂的对象的构建与它的表示分离(同构建不同表示),使得同样的构建过程可以创建不同的表示。

  一个人活到70岁以上,都会经历这样的几个阶段:婴儿,少年,青年,中年,老年。并且每个人在各个阶段肯定是不一样的,世界上不存在两个人在人生的这5个阶段的生活完全一样,但是活到70岁以上的人,都经历了这几个阶段是肯定的。实际上这是一个比较经典的建造者模式的例子了。

将复杂的内部创建封装在内部,对于外部调用的人来说,只需要传入建造者和建造工具,对于内部是如何建造成成品的,调用者无需关心。

建造者模式通常包括下面几个角色:

① Builder:一个抽象接口,用来规范产品对象的各个组成成分的建造。

② ConcreteBuilder:实现Builder接口,针对不同的商业逻辑,具体化复杂对象的各部分的创建,在建造过程完成后,提供产品的实例。

③ Director:指导者,调用具体建造者来创建复杂对象的各个部分,不涉及具体产品的信息,只负责保证对象各部分完整创建或按某种顺序创建。

④ Product:要创建的复杂对象。

与抽象工厂的区别:在建造者模式里,有个指导者,由指导者来管理建造者,用户是与指导者联系的,指导者联系建造者最后得到产品。即建造模式可以强制实行一种分步骤进行的建造过程。

这里写图片描述

Product和产品的部分Part接口

 public interface Product { }
 public interface Part { }

Builder:

 public interface Builder { 
    void buildPartOne(); 
    void buildPartTwo(); 
  
    Product getProduct(); 
  } 

ConcreteBuilder:

//具体建造工具
  public class ConcreteBuilder implements Builder { 
    Part partOne, partTwo; 

    public void buildPartOne() {
      //具体构建代码
    }; 
    public void buildPartTwo() { 
      //具体构建代码
    }; 
     public Product getProduct() { 
      //返回最后组装的产品
    }; 
  }

Director :

 public class Director {
    private Builder builder; 
  
    public Director( Builder builder ) { 
      this.builder = builder; 
    } 
    public void construct() { 
      builder.buildPartOne();
      builder.buildPartTwo();
    } 
  } 

建造:

ConcreteBuilder builder = new ConcreteBuilder();
Director director = new Director(builder); 
//开始各部分建造 
director.construct(); 
Product product = builder.getResult();

优点:

客户端不必知道产品内部组成的细节。

具体的建造者类之间是相互独立的,对系统的扩展非常有利。

由于具体的建造者是独立的,因此可以对建造过程逐步细化,而不对其他的模块产生任何影响。

使用场合:

创建一些复杂的对象时,这些对象的内部组成构件间的建造顺序是稳定的,但是对象的内部组成构件面临着复杂的变化

要创建的复杂对象的算法,独立于该对象的组成部分,也独立于组成部分的装配方法时。

6.1 Android中的Builder

android中的Dialog就使用了Builder Pattern,下面来看看AlertDialog的部分源码。

371    public static class Builder {
372        private final AlertController.AlertParams P;
373        private int mTheme;

393        public Builder(Context context, int theme) {
394            P = new AlertController.AlertParams(new ContextThemeWrapper(
395                    context, resolveDialogTheme(context, theme)));
396            mTheme = theme;
397        }

AlertDialog的Builder 是一个静态内部类,没有定义Builder 的抽象接口。
对AlertDialog设置的属性会保存在Build类的成员变量P(AlertController.AlertParams)中。

Builder类中部分方法:

416        public Builder setTitle(int titleId) {
417            P.mTitle = P.mContext.getText(titleId);
418            return this;
419        }
452        public Builder setMessage(int messageId) {
453            P.mMessage = P.mContext.getText(messageId);
454            return this;
455        }
525        public Builder setPositiveButton(CharSequence text, final OnClickListener listener) {
526            P.mPositiveButtonText = text;
527            P.mPositiveButtonListener = listener;
528            return this;
529        }

而show()方法会返回一个结合上面设置的dialog实例

991        public AlertDialog show() { 992 AlertDialog dialog = create();
993            dialog.show();
994            return dialog;
995        }
996    }
997    
998}
972        public AlertDialog create() {
973            final AlertDialog dialog = new AlertDialog(P.mContext, mTheme, false);
974            P.apply(dialog.mAlert);
975            dialog.setCancelable(P.mCancelable);
976            if (P.mCancelable) {
977                dialog.setCanceledOnTouchOutside(true);
978            }
979            dialog.setOnCancelListener(P.mOnCancelListener);
980            dialog.setOnDismissListener(P.mOnDismissListener);
981            if (P.mOnKeyListener != null) {
982                dialog.setOnKeyListener(P.mOnKeyListener);
983            }
984            return dialog;
985        }

简单建造:

new AlertDialog.Builder(context)
 .setTitle("标题") 
 .setMessage("消息框")
 .setPositiveButton("确定", null)
 .show();

7. Memento(备忘录模式)

备忘录模式又叫做快照模式(Snapshot Pattern)或Token模式,是对象的行为模式。

备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下,将一个对象的状态捕捉(Capture)住,并外部化,存储起来,从而可以在将来合适的时候把这个对象还原到存储起来的状态。备忘录模式常常与命令模式和迭代子模式一同使用。

备忘录模式所涉及的角色有三个:

① Originator(发起人): 负责创建一个备忘录Memento,用以记录当前时刻它的内部状态,并可使用备忘录恢复内部状态。Originator可根据需要决定Memento存储Originator的哪些内部状态。

② Memento(备忘录): 负责存储Originnator对象的内部状态,并可防止Originator以外的其他对象访问备忘录Memento,备忘录有两个接口,Caretaker只能看到备忘录的窄接口,它只能将备忘录传递给其他对象。

③、 Caretaker(管理者):负责保存好备忘录Memento,不能对备忘录的内容进行操作或检查。

这里写图片描述

public class Originator {

    private String state;
    /** * 工厂方法,返回一个新的备忘录对象 */
    public Memento createMemento(){
        return new Memento(state);
    }
    /** * 将发起人恢复到备忘录对象所记载的状态 */
    public void restoreMemento(Memento memento){
        this.state = memento.getState();
    }

    public String getState() {
        return state;
    }

    public void setState(String state) {
        this.state = state;
        System.out.println("当前状态:" + this.state);
    }

}
public class Memento {

    private String state;

    public Memento(String state){
        this.state = state;
    }

    public String getState() {
        return state;
    }

    public void setState(String state) {
        this.state = state;
    }

}
public class Caretaker {

    private Memento memento;
    /** * 备忘录的取值方法 */
    public Memento retrieveMemento(){
        return this.memento;
    }
    /** * 备忘录的赋值方法 */
    public void saveMemento(Memento memento){
        this.memento = memento;
    }
}

使用:

Originator o = new Originator();
Caretaker c = new Caretaker();
//改变负责人对象的状态
o.setState("On");
//创建备忘录对象,并将发起人对象的状态储存起来
 c.saveMemento(o.createMemento());
//修改发起人的状态
o.setState("Off");
//恢复发起人对象的状态
 o.restoreMemento(c.retrieveMemento());

不需要了解对象的内部结构的情况下备份对象的状态,方便以后恢复。

7.1 Android中的Memento

Activity的onSaveInstanceState和onRestoreInstanceState就是通过Bundle(相当于备忘录对象)这种序列化的数据结构来存储Activity的状态,至于其中存储的数据结构,这两个方法不用关心。

还是看一下源码:

1365    protected void onSaveInstanceState(Bundle outState) {
1366        outState.putBundle(WINDOW_HIERARCHY_TAG, mWindow.saveHierarchyState());
1367        Parcelable p = mFragments.saveAllState();
1368        if (p != null) {
1369            outState.putParcelable(FRAGMENTS_TAG, p);
1370        }
1371        getApplication().dispatchActivitySaveInstanceState(this, outState);
1372    }
1019    protected void onRestoreInstanceState(Bundle savedInstanceState) {
1020        if (mWindow != null) {
1021            Bundle windowState = savedInstanceState.getBundle(WINDOW_HIERARCHY_TAG);
1022            if (windowState != null) {
1023                mWindow.restoreHierarchyState(windowState);
1024            }
1025        }
1026    }

8、其他

当然还有其他的很多设计模式没有说明,以后有时间在继续整理。

那么问题来了,什么是设计模式?

这里写图片描述

设计模式是前辈、大牛在实际编程中对遇到的问题解决方案的抽象。

转自:http://blog.csdn.net/amazing7/article/details/51719404

工厂方法模式

8.1 女娲造人的故事

东汉《风俗通》记录了一则神话故事:“开天辟辟,未有人民,女娲搏,黄土作人……”,讲述的内容就是大家非常熟悉的女娲造人的故事。开天辟地之初,大地上并没有生物,只有苍茫大地,纯粹而洁净的自然环境,寂静而又寂寞,于是女娲决定创造一个新物种(即人类)来增加世界的繁荣,怎么制造呢?

别忘了女娲是神仙,没有办不到的事情,造人的过程是这样的:首先,女娲采集黄土捏成人的形状,然后放到八卦炉中烧制,最后放置到大地上生长,工艺过程是没有错的,但是意外随时都会发生:

第一次烤泥人,兹兹兹兹,感觉应该熟了,往大地上一放,哇,没烤熟!于是一个白人诞生了!(这也是缺乏经验的最好证明)

第二次烤泥人,兹兹兹兹兹兹兹兹,上一次没烤熟,这次多烤一会儿,放到世间一看,嘿,熟过头了,于是黑人诞生了!

第三次烤泥人,兹~~兹~~兹~~,一边烧制一边察看,直到表皮微黄,嘿,真正好,于是黄色人种出现了!

这个造人过程是比较有意思的,是不是可以通过软件开发来实现这个过程呢?古人云“三人行,必有我师焉”,在面向对象的思维中,万物皆对象,是对象我们就可以通过软件设计来实现。首先对造人过程进行分析,该过程涉及三个对象:女娲、八卦炉、三种不同肤色的人,女娲可以使用场景类Client来表示,八卦炉类似于一个工厂,负责制造生产产品(即人类):三种不同肤色的人,他们都是同一个接口下的不同实现类,都是人嘛,只是肤色、语言不同,对于八卦炉来说都是它生产出的产品。分析完毕,我们就可以画出如图8-1所示类图。

clip_image002_thumb

图8-1 女娲造人类图

      类图比较简单,AbstractHumanFactory是一个抽象类,定义了一个八卦炉都具有的整体功能,HumanFactory为实现类,完成具体的任务:创建人类;Human接口是人类的总称,其三个实现类分别为三类人种;NvWa类是一个场景类,负责模拟这个场景,执行相关的任务。

我们定义的每个人种都有两个方法:getColor(获得人的皮肤颜色)和talk(交谈),其源代码如代码清单8-1所示。


public interface Human {

//每个人种的皮肤都有相应的颜色

public void getColor();

//人类会说话

public void talk();

}

代码清单8-1 人类总称

 

接口Human是对人类的总称,每个人种都至少具有两个方法,黑色人种、黄色人种、白色人种的代码分别如代码清单8-2、8-3、8-4所示。

代码清单8-2 黑色人种

public class BlackHuman implements Human {
public void getColor(){
System.out.println("黑色人种的皮肤颜色是黑色的!");
}
public void talk() {
System.out.println("黑人会说话,一般人听不懂。");
}
}

代码清单8-3 黄色人种

public class YellowHuman implements Human {
public void getColor(){
System.out.println("黄色人种的皮肤颜色是黄色的!");
}
public void talk() {
System.out.println("黄色人种会说话,一般说的都是双字节。");
}
}

代码清单8-4 白色人种

public class WhiteHuman implements Human {
public void getColor(){
System.out.println("白色人种的皮肤颜色是白色的!");
}
public void talk() {
System.out.println("白色人种会说话,一般都是但是单字节。");
}
}

所有的人种定义完毕,下一步就是定义一个八卦炉,然后烧制人类。我们想象一下,女娲最可能给八卦炉下达什么样的生产命令呢?应该是“给我生产出一个黄色人种(YellowHuman类)”,而不会是“给我生产一个会走、会跑、会说话、皮肤是黄色的人种”,因为这样的命令增加了交流的成本,作为一个生产的管理者,只要知道生产什么就可以了,而不需要事物的具体信息。通过分析,我们发现八卦炉生产人类的方法输入参数类型应该是Human接口的实现类,这也解释了为什么类图上的AbstractHumanFactory抽象类中createHuman方法的参数为Class类型。其源代码如代码清单8-5所示。

代码清单8-5 抽象人类创建工厂

public abstract class AbstractHumanFactory {
public abstract Human createHuman(Class<? extends Human> c);
}

注意,我们在这里采用了JDK 1.5的新特性:泛型(Generic),通过定义泛型对createHuman的输入参数产生两层限制:

  • 必须是Class类型;
  • 必须是Human的实现类;

其中的“?”表示的是,只要实现了Human接口的类都可以作为参数,泛型是JDK 1.5中的一个非常重要的新特性,它减少了对象间的转换,约束其输入参数类型,对Collection集合下的实现类都可以定义泛型。有关泛型详细知识,请参考相关的Java语法文档。

目前女娲只有一个八卦炉,其实现了生产人类的方法,如代码清单8-6所示。

代码清单8-6 人类创建工厂

public class HumanFactory extends AbstractHumanFactory {
public Human createHuman(Class<? extends Human> c){
//定义一个生产的人种
Human human=null;
try {
//产生一个人种
human = (Human)Class.forName(c.getName()).newInstance();
} catch (Exception e) {
System.out.println("人种生成错误!");
}
return human;
}
}

人种有了,八卦炉也有了,剩下的工作就是女娲采集黄土,然后命令八卦炉开始生产,其过程如代码清单8-7所示。

代码清单8-7 女娲类

public class NvWa {
public static void main(String[] args) {
//声明阴阳八卦炉
AbstractHumanFactory YinYangLu = new HumanFactory();
//女娲第一次造人,火候不足,缺陷产品
System.out.println("--造出的第一批人是白色人种--");
Human whiteHuman = YinYangLu.createHuman(WhiteHuman.class);
whiteHuman.getColor();
whiteHuman.talk();
//女娲第二次造人,火候过足,又是次品,
System.out.println("\n--造出的第二批人是黑色人种--");
Human blackHuman = YinYangLu.createHuman(BlackHuman.class);
blackHuman.getColor();
blackHuman.talk();
//第三次造人,火候刚刚好,优品!黄色人种
System.out.println("\n--造出的第三批人是黄色人种--");
Human yellowHuman = YinYangLu.createHuman(YellowHuman.class);
yellowHuman.getColor();
yellowHuman.talk();
}
}

人种有了,八卦炉有了,负责生产的女娲也有了,激动人心的时刻到来了,我们运行一下,结果如下所示。

–造出的第一批人是白色人种–

白色人种的皮肤颜色是白色的!

白色人种会说话,一般都是但是单字节。

–造出的第二批人是黑色人种–

黑色人种的皮肤颜色是黑色的!

黑人会说话,一般人听不懂。

–造出的第三批人是黄色人种–

黄色人种的皮肤颜色是黄色的!

黄色人种会说话,一般说的都是双字节。

哇,人类的生产过程就展现出来了!这个世界就热闹起来了,黑人、白人、黄人都开始活动了,这也正是我们现在的真实世界。以上就是工厂方法模式(没错,对该部分有疑问,请继续阅读下去)。

8.2 工厂方法模式的定义

工厂方法模式使用的频率非常高,在我们日常的开发中总能见到它的身影。其定义为:

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses。定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

工厂方法模式的通用类图如图8-2所示。

clip_image004_2

图8-2 工厂方法模式通用类图

      在工厂方法模式中,抽象产品类Product负责定义产品的共性,实现对事物最抽象定义;Creator为抽象创建类,也就是抽象工厂,具体如何创建产品类是由具体的实现工厂ConcreteCreator完成的。工厂方法模式的变种较多,我们来看一个比较实用的通用源码。

抽象产品类代码如代码清单8-8所示。

代码清单8-8 抽象产品类

public abstract class Product {
//产品类的公共方法
public void method1(){
//业务逻辑处理
}
//抽象方法
public abstract void method2();
}

具体的产品类可以有多个,都继承于抽象产品类,其源代码如代码清单8-9所示。

代码清单8-9 具体产品类

public class ConcreteProduct1 extends Product {
public void method2() {
//业务逻辑处理
}
}
public class ConcreteProduct2 extends Product {
public void method2() {
//业务逻辑处理
}
}

抽象工厂类负责定义产品对象的产生,源代码如代码清单8-10所示。

代码清单8-10 抽象工厂类

public abstract class Creator {
/*
* 创建一个产品对象,其输入参数类型可以自行设置
* 通常为String、Enum、Class等,当然也可以为空
*/
public abstract Product createProduct(Class<? extends Product> c);
}

具体如何产生一个产品的对象,是由具体的工厂类实现的,如代码清单8-11所示。

代码清单8-11 具体工厂类

public class ConcreteCreator extends Creator {
public Product createProduct(Class<? extends Product> c) {
Product product=null;
try {
product = (Product)Class.forName(c.getName()).newInstance();
} catch (Exception e) {
//异常处理
}
return product;
}
}

场景类的调用方法如代码清单8-12所示。

代码清单8-12 场景类

public class Client {
public static void main(String[] args) {
Creator creator = new ConcreteCreator();
Product product = creator.createProduct(ConcreteProduct1.class);
/*
* 继续业务处理
*/
}
}

该通用代码是一个比较实用、易扩展的框架,读者可以根据实际项目需要进行扩展。

8.3 工厂方法模式的应用

8.3.1 工厂方法模式的优点

首先,良好的封装性,代码结构清晰。一个对象创建是有条件约束的,如一个调用者需要一个具体的产品对象,只要知道这个产品的类名(或约束字符串)就可以了,不用知道创建对象的艰辛过程,减少模块间的耦合。

其次,工厂方法模式的扩展性非常优秀。在增加产品类的情况下,只要适当地修改具体的工厂类或扩展一个工厂类,就可以完成“拥抱变化”。例如在我们的例子中,需要增加一个棕色人种,则只需要增加一个BrownHuman类,工厂类不用任何修改就可完成系统扩展。

再次,屏蔽产品类。这一特点非常重要,产品类的实现如何变化,调用者都不需要关心,它只需要关心产品的接口,只要接口保持不表,系统中的上层模块就不要发生变化,因为产品类的实例化工作是由工厂类负责,一个产品对象具体由哪一个产品生成是由工厂类决定的。在数据库开发中,大家应该能够深刻体会到工厂方法模式的好处:如果使用JDBC连接数据库,数据库从MySql切换到Oracle,需要改动地方就是切换一下驱动名称(前提条件是SQL语句是标准语句),其他的都不需要修改,这是工厂方法模式灵活性的一个直接案例。

最后,工厂方法模式是典型的解耦框架。高层模块值需要知道产品的抽象类,其他的实现类都不用关心,符合迪米特原则,我不需要的就不要去交流;也符合依赖倒转原则,只依赖产品类的抽象;当然也符合里氏替换原则,使用产品子类替换产品父类,没问题!

8.3.2 工厂方法模式的使用场景

首先,工厂方法模式是new一个对象的替代品,所以在所有需要生成对象的地方都可以使用,但是需要慎重地考虑是否要增加一个工厂类进行管理,增加代码的复杂度。

其次,需要灵活的、可扩展的框架时,可以考虑采用工厂方法模式。万物皆对象,那万物也就皆产品类,例如需要设计一个连接邮件服务器的框架,有三种网络协议可供选择:POP3、IMAP、HTTP,我们就可以把这三种连接方法作为产品类,定义一个接口如IConnectMail,然后定义对邮件的操作方法,三个具体的产品类(也就是连接方式)进行不同的实现,再定义一个工厂方法,按照不同的传入条件,选择不同的连接方式。如此设计,可以做到完美的扩展,如某些邮件服务器提供了WebService接口,很好,我们只要增加一个产品类就可以了。

再次,工厂方法模式可以用在异构项目中,例如通过WebService与一个非Java的项目交互,虽然WebService号称是可以做到异构系统的同构化,但是在实际的开发中,还是会碰到很多问题,如类型问题、WSDL文件的支持问题,等等,从WSDL中产生的对象都认为是一个产品,然后由一个具体的工厂类进行管理,减少与外围系统的耦合。

最后,可以使用在测试驱动开发的框架下,例如,测试一个类A,就需要把与类A有关联关系的类B也同时产生出来,我们可以使用工厂方法模式把类B虚拟出来,避免类A与类B的耦合。目前由于JMock和EasyMock的诞生,该使用场景已经弱化了,读者可以在遇到此种情况时直接考虑使用JMock或EasyMock。

8.4 工厂方法模式的扩展

工厂方法模式有很多扩展,而且与其他模式结合使用威力更大,下面将介绍四种扩展。

  • 缩小为简单工厂模式

我们这样考虑一个问题:一个模块仅需要一个工厂类,没有必要把它产生出来,使用静态的方法就可以了,根据这一要求,我们把上例中的AbstarctHumanFactory修改一下,类图如图8-3所示。

clip_image006_2

图8-3 简单工厂模式类图

      我们在类图中去掉了AbstractHumanFactory抽象类,同时把createHuman方法设置为静态类型,简化了类的创建过程,变更的源码仅仅是HumanFactory和NvWa类,HumanFactory如代码清单8-13所示。

代码清单8-13 简单工厂模式中的工厂类

public class HumanFactory {

public static Human createHuman(Class<? extends Human> c){

//定义一个生产出的人种

Human human=null;

try {

//产生一个人种

human = (Human)Class.forName(c.getName()).newInstance();

} catch (Exception e) {

System.out.println(“人种生成错误!”);

}

return human;

}

}

运行结果没有发生变化,但是我们的类图变简单了,而且调用者也比较简单,该模式是工厂方法模式的弱化,因为简单,所以被称为简单工厂模式(Simple Factory Pattern),也叫做静态工厂模式。在实际项目中,采用该方法的案例还是比较多的,其缺点是工厂类的扩展比较困难,不符合开闭原则,但它仍然是一个非常实用的设计模式。

  • 升级为多个工厂类

当我们在做一个比较复杂的项目时,经常会遇到初始化一个对象很耗费精力的情况,所有的产品类都放到一个工厂方法中进行初始化会使代码结构不清晰。例如,一个产品类有5个具体实现,每个实现类的初始化(不仅仅是new,初始化包括new一个对象,并对对象设置一定的初始值)方法都不相同,如果写在一个工厂方法中,势必会导致该方法巨大无比,那怎么办?

考虑到需要结构清晰,我们就为每个产品定义一个创造者,然后由调用者自己去选择与哪个工厂方法关联。我们还是以女娲造人为例,每个人种都有一个固定的八卦炉,分别造出黑色人种、白色人种、黄色人种,修改后的类图如图8-4所示。

clip_image008_2

图8-4 多个工厂类的类图

      每个人种(具体的产品类)都对应了一个创建者,每个创建者都独立负责创建对应的产品对象,非常符合单一职责原则,按照这种模式我们来看代码变化。

抽象工厂类如代码清单8-15所示。

代码清单8-15 多工厂模式的抽象工厂类

public abstract class AbstractHumanFactory {
public abstract Human createHuman();
}

注意 抽象方法中已经不再需要传递相关参数了,因为每一个具体的工厂都已经非常明确自己的职责:创建自己负责的产品类对象。

黑色人种的创建工厂如代码清单8-16所示。

代码清单8-16 黑色人种的创建类

public class BlackHumanFactory extends AbstractHumanFactory {
public Human createHuman() {
return new BlackHuman();
}
}

黄色人种的创建工厂如代码清单8-17所示。

代码清单8-17 黄色人种的创建类

public class YellowHumanFactory extends AbstractHumanFactory {
public Human createHuman() {
return new YellowHuman();
}
}

白色人种的创建工厂如代码清单8-18所示。

代码清单8-18 白色人种的创建类

public class YellowHumanFactory extends AbstractHumanFactory {
public Human createHuman() {
return new WhiteHuman();
}
}

三个具体的创建工厂都非常简单,但是,如果一个系统比较复杂时工厂类也会相应变复杂。场景类NvWa修改后的代码如代码清单8-19所示。

代码清单8-19 场景类NvWa

public class NvWa {
public static void main(String[] args) {
//女娲第一次造人,火候不足,缺陷产品
System.out.println("--造出的第一批人是白色人种--");
Human whiteHuman = (new WhiteHumanFactory()).createHuman();
whiteHuman.getColor();
whiteHuman.talk();
//女娲第二次造人,火候过足,又是次品,
System.out.println("\n--造出的第二批人是黑色人种--");
Human blackHuman = (new BlackHumanFactory()).createHuman();
blackHuman.getColor();
blackHuman.talk();
//第三次造人,火候正正好,优品!黄色人种
System.out.println("\n--造出的第三批人是黄色人种--");
Human yellowHuman = (new YellowHumanFactory()).createHuman();
yellowHuman.getColor();
yellowHuman.talk();
}
}

运行结果还是相同。我们回顾一下,每一个产品类都对应了一个创建类,好处就是创建类的职责清晰,而且结构简单,但是给扩展性和维护性带来了一定的影响。为什么这么说呢?如果要扩展一个产品类,就需要建立一个相应的工厂类,这样就增加了扩展的难度。因为工厂类和产品类的数量相同,维护时需要考虑两个对象之间的关系。

当然,在复杂的应用中一般采用多工厂的方法,然后再增加一个协调类,避免调用者与各个子工厂交流,协调类的作用是封装子工厂类,对高层模块提供统一的访问接口。

  • 替代单例模式

第7章讲述了单例模式以及扩展出的多例模式,并且指出了单例和多例的一些缺点,我们是不是可以采用工厂方法模式实现单例模式的功能呢?单例模式的核心要求就是在内存中只有一个对象,通过工厂方法模式也可以只在内存中生产一个对象。类图如图8-5所示。

clip_image010_2

图8-5 工厂方法模式替代单例模式类图

      非常简单的类图,Singleton定义了一个private的无参构造函数,目的是不允许通过new的方式创建一个对象,如代码清单8-20所示。

代码清单8-20 单例类

public class Singleton {
//不允许通过new产生一个对象
private Singleton(){
}
public void doSomething(){
//业务处理
}
}

Singleton保证不能通过正常的渠道建立一个对象,那SingletonFactory如何建立一个单例对象呢?答案是通过反射方式创建,如代码清单8-21所示。

代码清单8-21 负责生成单例的工厂类

public class SingletonFactory {
private static Singleton singleton;
static{
try {
Class cl= Class.forName(Singleton.class.getName());
//获得无参构造
Constructor constructor=cl.getDeclaredConstructor();
//设置无参构造是可访问的
constructor.setAccessible(true);
//产生一个实例对象
singleton = (Singleton)constructor.newInstance();
} catch (Exception e) {
//异常处理
}
}
public static Singleton getSingleton(){
return singleton;
}
}

通过获得类构造器,然后设置访问权限,生成一个对象,然后提供外部访问,保证内存中的对象唯一。当然,其他类也可以通过反射的方式建立一个单例对象,确实如此,但是一个项目或团队是有章程和规范的,何况已经提供了一个获得单例对象的方法,为什么还要重新创建一个新对象呢?除非是有人作恶。

以上通过工厂方法模式创建了一个单例对象,该框架可以继续扩展,在一个项目中可以产生一个单例构造器,所有需要产生单例的类都遵循一定的规则(构造方法是private),然后通过扩展该框架,只要输入一个类型就可以获得唯一的一个实例。

  • 延迟初始化

何为延迟初始化(Lazy initialization)?一个对象被消费完毕后,并不立刻释放,工厂类保持其初始状态,等待再次被使用。延迟初始化是工厂方法模式的一个扩展应用,其通用类图如图8-6所示。

clip_image012_2

图8-6 延迟初始化通用类图

      ProductFactory负责产品类对象的创建工作,并且通过prMap变量产生一个缓存,对需要再次被重用的对象保留,Product和ConcreteProduct是一个示例代码,请参考代码清单8-8和8-9。ProductFactory如代码清单8-22所示。

代码清单8-22 延迟加载的工厂类

public class ProductFactory {
private static final Map<String,Product> prMap = new HashMap();
public static synchronized Product createProduct(String type) throws Exception{
Product product =null;
//如果Map中已经有这个对象
if(prMap.containsKey(type)){
product = prMap.get(type);
}else{
if(type.equals("Product1")){
product = new ConcreteProduct1();
}else{
product = new ConcreteProduct2();
}
//同时把对象放到缓存容器中
prMap.put(type,product);
}
return product;
}
}

代码还比较简单,通过定义一个Map容器,容纳所有产生的对象,如果在Map容器中已经有的对象,则直接取出返回,如果没有,则根据需要的类型产生一个对象并放入到Map容器中,以方便下次调用。

延迟加载框架是可以扩展的,例如限制某一个产品类的最大实例化数量,可以通过判断Map中已有的对象数量来实现,这样的处理是非常有意义的,例如JDBC连接数据库,都会要求设置一个MaxConnections最大连接数量,该数量就是内存中最大实例化的数量。

延迟加载还可以使用在一个对象初始化比较复杂的情况,例如硬件访问,涉及多方面的交互,则可以通过延迟加载降低对象的产生和销毁带来的复杂性。

8.5 最佳实践

工厂方法模式在项目中使用得非常频繁,以至于很多代码中都包含工厂方法模式。该模式几乎尽人皆知,但不是每个人都能用得好。熟能生巧,熟练掌握该模式,多思考工厂方法如何应用,而且工厂方法模式还可以与其他模式混合使用(例如模版方法模式、单例模式、原型模式等),变化出无穷的优秀设计,这也正是软件设计和开发的乐趣所在。

23种设计模式(12):策略模式

定义:定义一组算法,将每个算法都封装起来,并且使他们之间可以互换。

类型:行为类模式

类图:

       策略模式是对算法的封装,把一系列的算法分别封装到对应的类中,并且这些类实现相同的接口,相互之间可以替换。在前面说过的行为类模式中,有一种模式也是关注对算法的封装——模版方法模式,对照类图可以看到,策略模式与模版方法模式的区别仅仅是多了一个单独的封装类Context,它与模版方法模式的区别在于:在模版方法模式中,调用算法的主体在抽象的父类中,而在策略模式中,调用算法的主体则是封装到了封装类Context中,抽象策略Strategy一般是一个接口,目的只是为了定义规范,里面一般不包含逻辑。其实,这只是通用实现,而在实际编程中,因为各个具体策略实现类之间难免存在一些相同的逻辑,为了避免重复的代码,我们常常使用抽象类来担任Strategy的角色,在里面封装公共的代码,因此,在很多应用的场景中,在策略模式中一般会看到模版方法模式的影子。

 

策略模式的结构

  • 封装类:也叫上下文,对策略进行二次封装,目的是避免高层模块对策略的直接调用。
  • 抽象策略:通常情况下为一个接口,当各个实现类中存在着重复的逻辑时,则使用抽象类来封装这部分公共的代码,此时,策略模式看上去更像是模版方法模式。
  • 具体策略:具体策略角色通常由一组封装了算法的类来担任,这些类之间可以根据需要自由替换。

策略模式代码实现

interface IStrategy {
	public void doSomething();
}
class ConcreteStrategy1 implements IStrategy {
	public void doSomething() {
		System.out.println("具体策略1");
	}
}
class ConcreteStrategy2 implements IStrategy {
	public void doSomething() {
		System.out.println("具体策略2");
	}
}
class Context {
	private IStrategy strategy;
	
	public Context(IStrategy strategy){
		this.strategy = strategy;
	}
	
	public void execute(){
		strategy.doSomething();
	}
}

public class Client {
	public static void main(String[] args){
		Context context;
		System.out.println("-----执行策略1-----");
		context = new Context(new ConcreteStrategy1());
		context.execute();

		System.out.println("-----执行策略2-----");
		context = new Context(new ConcreteStrategy2());
		context.execute();
	}
}

 

策略模式的优缺点

       策略模式的主要优点有:

  • 策略类之间可以自由切换,由于策略类实现自同一个抽象,所以他们之间可以自由切换。
  • 易于扩展,增加一个新的策略对策略模式来说非常容易,基本上可以在不改变原有代码的基础上进行扩展。
  • 避免使用多重条件,如果不使用策略模式,对于所有的算法,必须使用条件语句进行连接,通过条件判断来决定使用哪一种算法,在上一篇文章中我们已经提到,使用多重条件判断是非常不容易维护的。

       策略模式的缺点主要有两个:

  • 维护各个策略类会给开发带来额外开销,可能大家在这方面都有经验:一般来说,策略类的数量超过5个,就比较令人头疼了。
  • 必须对客户端(调用者)暴露所有的策略类,因为使用哪种策略是由客户端来决定的,因此,客户端应该知道有什么策略,并且了解各种策略之间的区别,否则,后果很严重。例如,有一个排序算法的策略模式,提供了快速排序、冒泡排序、选择排序这三种算法,客户端在使用这些算法之前,是不是先要明白这三种算法的适用情况?再比如,客户端要使用一个容器,有链表实现的,也有数组实现的,客户端是不是也要明白链表和数组有什么区别?就这一点来说是有悖于迪米特法则的。

 

适用场景

        做面向对象设计的,对策略模式一定很熟悉,因为它实质上就是面向对象中的继承和多态,在看完策略模式的通用代码后,我想,即使之前从来没有听说过策略模式,在开发过程中也一定使用过它吧?至少在在以下两种情况下,大家可以考虑使用策略模式,

  • 几个类的主要逻辑相同,只在部分逻辑的算法和行为上稍有区别的情况。
  • 有几种相似的行为,或者说算法,客户端需要动态地决定使用哪一种,那么可以使用策略模式,将这些算法封装起来供客户端调用。

       策略模式是一种简单常用的模式,我们在进行开发的时候,会经常有意无意地使用它,一般来说,策略模式不会单独使用,跟模版方法模式、工厂模式等混合使用的情况比较多。

 

 

23种设计模式(2):工厂方法模式

定义:定义一个用于创建对象的接口,让子类决定实例化哪一个类,工厂方法使一个类的实例化延迟到其子类。

类型:创建类模式

类图:

工厂方法模式代码

interface IProduct {
	public void productMethod();
}

class Product implements IProduct {
	public void productMethod() {
		System.out.println("产品");
	}
}

interface IFactory {
	public IProduct createProduct();
}

class Factory implements IFactory {
	public IProduct createProduct() {
		return new Product();
	}
}

public class Client {
	public static void main(String[] args) {
		IFactory factory = new Factory();
		IProduct prodect = factory.createProduct();
		prodect.productMethod();
	}
}

工厂模式:

        首先需要说一下工厂模式。工厂模式根据抽象程度的不同分为三种:简单工厂模式(也叫静态工厂模式)、本文所讲述的工厂方法模式、以及抽象工厂模式。工厂模式是编程中经常用到的一种模式。它的主要优点有:

  • 可以使代码结构清晰,有效地封装变化。在编程中,产品类的实例化有时候是比较复杂和多变的,通过工厂模式,将产品的实例化封装起来,使得调用者根本无需关心产品的实例化过程,只需依赖工厂即可得到自己想要的产品。
  • 对调用者屏蔽具体的产品类。如果使用工厂模式,调用者只关心产品的接口就可以了,至于具体的实现,调用者根本无需关心。即使变更了具体的实现,对调用者来说没有任何影响。
  • 降低耦合度。产品类的实例化通常来说是很复杂的,它需要依赖很多的类,而这些类对于调用者来说根本无需知道,如果使用了工厂方法,我们需要做的仅仅是实例化好产品类,然后交给调用者使用。对调用者来说,产品所依赖的类都是透明的。

 

工厂方法模式:

       通过工厂方法模式的类图可以看到,工厂方法模式有四个要素:

  • 工厂接口。工厂接口是工厂方法模式的核心,与调用者直接交互用来提供产品。在实际编程中,有时候也会使用一个抽象类来作为与调用者交互的接口,其本质上是一样的。
  • 工厂实现。在编程中,工厂实现决定如何实例化产品,是实现扩展的途径,需要有多少种产品,就需要有多少个具体的工厂实现。
  • 产品接口。产品接口的主要目的是定义产品的规范,所有的产品实现都必须遵循产品接口定义的规范。产品接口是调用者最为关心的,产品接口定义的优劣直接决定了调用者代码的稳定性。同样,产品接口也可以用抽象类来代替,但要注意最好不要违反里氏替换原则。
  • 产品实现。实现产品接口的具体类,决定了产品在客户端中的具体行为。

        前文提到的简单工厂模式跟工厂方法模式极为相似,区别是:简单工厂只有三个要素,他没有工厂接口,并且得到产品的方法一般是静态的。因为没有工厂接口,所以在工厂实现的扩展性方面稍弱,可以算所工厂方法模式的简化版,关于简单工厂模式,在此一笔带过。

      

适用场景:

        不管是简单工厂模式,工厂方法模式还是抽象工厂模式,他们具有类似的特性,所以他们的适用场景也是类似的。

        首先,作为一种创建类模式,在任何需要生成复杂对象的地方,都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式,而简单对象,特别是只需要通过new就可以完成创建的对象,无需使用工厂模式。如果使用工厂模式,就需要引入一个工厂类,会增加系统的复杂度。

       其次,工厂模式是一种典型的解耦模式,迪米特法则在工厂模式中表现的尤为明显。假如调用者自己组装产品需要增加依赖关系时,可以考虑使用工厂模式。将会大大降低对象之间的耦合度。

       再次,由于工厂模式是依靠抽象架构的,它把实例化产品的任务交由实现类完成,扩展性比较好。也就是说,当需要系统有比较好的扩展性时,可以考虑工厂模式,不同的产品用不同的实现工厂来组装。

      

典型应用

       要说明工厂模式的优点,可能没有比组装汽车更合适的例子了。场景是这样的:汽车由发动机、轮、底盘组成,现在需要组装一辆车交给调用者。假如不使用工厂模式,代码如下:

class Engine {
	public void getStyle(){
		System.out.println("这是汽车的发动机");
	}
}
class Underpan {
	public void getStyle(){
		System.out.println("这是汽车的底盘");
	}
}
class Wheel {
	public void getStyle(){
		System.out.println("这是汽车的轮胎");
	}
}
public class Client {
	public static void main(String[] args) {
		Engine engine = new Engine();
		Underpan underpan = new Underpan();
		Wheel wheel = new Wheel();
		ICar car = new Car(underpan, wheel, engine);
		car.show();
	}
}

        可以看到,调用者为了组装汽车还需要另外实例化发动机、底盘和轮胎,而这些汽车的组件是与调用者无关的,严重违反了迪米特法则,耦合度太高。并且非常不利于扩展。另外,本例中发动机、底盘和轮胎还是比较具体的,在实际应用中,可能这些产品的组件也都是抽象的,调用者根本不知道怎样组装产品。假如使用工厂方法的话,整个架构就显得清晰了许多。

interface IFactory {
	public ICar createCar();
}
class Factory implements IFactory {
	public ICar createCar() {
		Engine engine = new Engine();
		Underpan underpan = new Underpan();
		Wheel wheel = new Wheel();
		ICar car = new Car(underpan, wheel, engine);
		return car;
	}
}
public class Client {
	public static void main(String[] args) {
		IFactory factory = new Factory();
		ICar car = factory.createCar();
		car.show();
	}
}

        使用工厂方法后,调用端的耦合度大大降低了。并且对于工厂来说,是可以扩展的,以后如果想组装其他的汽车,只需要再增加一个工厂类的实现就可以。无论是灵活性还是稳定性都得到了极大的提高。

 

 

23种设计模式(3):抽象工厂模式

定义:为创建一组相关或相互依赖的对象提供一个接口,而且无需指定他们的具体类。

类型:创建类模式

类图:

抽象工厂模式与工厂方法模式的区别

        抽象工厂模式是工厂方法模式的升级版本,他用来创建一组相关或者相互依赖的对象。他与工厂方法模式的区别就在于,工厂方法模式针对的是一个产品等级结构;而抽象工厂模式则是针对的多个产品等级结构。在编程中,通常一个产品结构,表现为一个接口或者抽象类,也就是说,工厂方法模式提供的所有产品都是衍生自同一个接口或抽象类,而抽象工厂模式所提供的产品则是衍生自不同的接口或抽象类。

        在抽象工厂模式中,有一个产品族的概念:所谓的产品族,是指位于不同产品等级结构中功能相关联的产品组成的家族。抽象工厂模式所提供的一系列产品就组成一个产品族;而工厂方法提供的一系列产品称为一个等级结构。我们依然拿生产汽车的例子来说明他们之间的区别。

        在上面的类图中,两厢车和三厢车称为两个不同的等级结构;而2.0排量车和2.4排量车则称为两个不同的产品族。再具体一点,2.0排量两厢车和2.4排量两厢车属于同一个等级结构,2.0排量三厢车和2.4排量三厢车属于另一个等级结构;而2.0排量两厢车和2.0排量三厢车属于同一个产品族,2.4排量两厢车和2.4排量三厢车属于另一个产品族。

        明白了等级结构和产品族的概念,就理解工厂方法模式和抽象工厂模式的区别了,如果工厂的产品全部属于同一个等级结构,则属于工厂方法模式;如果工厂的产品来自多个等级结构,则属于抽象工厂模式。在本例中,如果一个工厂模式提供2.0排量两厢车和2.4排量两厢车,那么他属于工厂方法模式;如果一个工厂模式是提供2.4排量两厢车和2.4排量三厢车两个产品,那么这个工厂模式就是抽象工厂模式,因为他提供的产品是分属两个不同的等级结构。当然,如果一个工厂提供全部四种车型的产品,因为产品分属两个等级结构,他当然也属于抽象工厂模式了。

抽象工厂模式代码

interface IProduct1 {
	public void show();
}
interface IProduct2 {
	public void show();
}

class Product1 implements IProduct1 {
	public void show() {
		System.out.println("这是1型产品");
	}
}
class Product2 implements IProduct2 {
	public void show() {
		System.out.println("这是2型产品");
	}
}

interface IFactory {
	public IProduct1 createProduct1();
	public IProduct2 createProduct2();
}
class Factory implements IFactory{
	public IProduct1 createProduct1() {
		return new Product1();
	}
	public IProduct2 createProduct2() {
		return new Product2();
	}
}

public class Client {
	public static void main(String[] args){
		IFactory factory = new Factory();
		factory.createProduct1().show();
		factory.createProduct2().show();
	}
}

抽象工厂模式的优点

        抽象工厂模式除了具有工厂方法模式的优点外,最主要的优点就是可以在类的内部对产品族进行约束。所谓的产品族,一般或多或少的都存在一定的关联,抽象工厂模式就可以在类内部对产品族的关联关系进行定义和描述,而不必专门引入一个新的类来进行管理。

 

抽象工厂模式的缺点

       产品族的扩展将是一件十分费力的事情,假如产品族中需要增加一个新的产品,则几乎所有的工厂类都需要进行修改。所以使用抽象工厂模式时,对产品等级结构的划分是非常重要的。

 

适用场景

       当需要创建的对象是一系列相互关联或相互依赖的产品族时,便可以使用抽象工厂模式。说的更明白一点,就是一个继承体系中,如果存在着多个等级结构(即存在着多个抽象类),并且分属各个等级结构中的实现类之间存在着一定的关联或者约束,就可以使用抽象工厂模式。假如各个等级结构中的实现类之间不存在关联或约束,则使用多个独立的工厂来对产品进行创建,则更合适一点。

 

总结

       无论是简单工厂模式,工厂方法模式,还是抽象工厂模式,他们都属于工厂模式,在形式和特点上也是极为相似的,他们的最终目的都是为了解耦。在使用时,我们不必去在意这个模式到底工厂方法模式还是抽象工厂模式,因为他们之间的演变常常是令人琢磨不透的。经常你会发现,明明使用的工厂方法模式,当新需求来临,稍加修改,加入了一个新方法后,由于类中的产品构成了不同等级结构中的产品族,它就变成抽象工厂模式了;而对于抽象工厂模式,当减少一个方法使的提供的产品不再构成产品族之后,它就演变成了工厂方法模式。

       所以,在使用工厂模式时,只需要关心降低耦合度的目的是否达到了。

 

23种设计模式(14):解释器模式

定义:给定一种语言,定义他的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中句子。

类型:行为类模式

类图:

        解释器模式是一个比较少用的模式,本人之前也没有用过这个模式。下面我们就来一起看一下解释器模式。

 

解释器模式的结构

  • 抽象解释器:声明一个所有具体表达式都要实现的抽象接口(或者抽象类),接口中主要是一个interpret()方法,称为解释操作。具体解释任务由它的各个实现类来完成,具体的解释器分别由终结符解释器TerminalExpression和非终结符解释器NonterminalExpression完成。
  • 终结符表达式:实现与文法中的元素相关联的解释操作,通常一个解释器模式中只有一个终结符表达式,但有多个实例,对应不同的终结符。终结符一半是文法中的运算单元,比如有一个简单的公式R=R1+R2,在里面R1和R2就是终结符,对应的解析R1和R2的解释器就是终结符表达式。                                
  • 非终结符表达式:文法中的每条规则对应于一个非终结符表达式,非终结符表达式一般是文法中的运算符或者其他关键字,比如公式R=R1+R2中,+就是非终结符,解析+的解释器就是一个非终结符表达式。非终结符表达式根据逻辑的复杂程度而增加,原则上每个文法规则都对应一个非终结符表达式。
  • 环境角色:这个角色的任务一般是用来存放文法中各个终结符所对应的具体值,比如R=R1+R2,我们给R1赋值100,给R2赋值200。这些信息需要存放到环境角色中,很多情况下我们使用Map来充当环境角色就足够了。

代码实现

class Context {}
abstract class Expression {
	public abstract Object interpreter(Context ctx);
}
class TerminalExpression extends Expression {
	public Object interpreter(Context ctx){
		return null;
	}
}
class NonterminalExpression extends Expression {
	public NonterminalExpression(Expression...expressions){
		
	}
	public Object interpreter(Context ctx){
		return null;
	}
}
public class Client {
	public static void main(String[] args){
		String expression = "";
		char[] charArray = expression.toCharArray();
		Context ctx = new Context();
		Stack<Expression> stack = new Stack<Expression>();
		for(int i=0;i<charArray.length;i++){
			//进行语法判断,递归调用
		}
		Expression exp = stack.pop();
		exp.interpreter(ctx);
	}
}

        文法递归的代码部分需要根据具体的情况来实现,因此在代码中没有体现。抽象表达式是生成语法集合的关键,每个非终结符表达式解释一个最小的语法单元,然后通过递归的方式将这些语法单元组合成完整的文法,这就是解释器模式。

 

解释器模式的优缺点

        解释器是一个简单的语法分析工具,它最显著的优点就是扩展性,修改语法规则只需要修改相应的非终结符就可以了,若扩展语法,只需要增加非终结符类就可以了。

        但是,解释器模式会引起类的膨胀,每个语法都需要产生一个非终结符表达式,语法规则比较复杂时,就可能产生大量的类文件,为维护带来非常多的麻烦。同时,由于采用递归调用方法,每个非终结符表达式只关心与自己相关的表达式,每个表达式需要知道最终的结果,必须通过递归方式,无论是面向对象的语言还是面向过程的语言,递归都是一个不推荐的方式。由于使用了大量的循环和递归,效率是一个不容忽视的问题。特别是用于解释一个解析复杂、冗长的语法时,效率是难以忍受的。

 

解释器模式的适用场景

        在以下情况下可以使用解释器模式:

  • 有一个简单的语法规则,比如一个sql语句,如果我们需要根据sql语句进行rm转换,就可以使用解释器模式来对语句进行解释。
  • 一些重复发生的问题,比如加减乘除四则运算,但是公式每次都不同,有时是a+b-c*d,有时是a*b+c-d,等等等等个,公式千变万化,但是都是由加减乘除四个非终结符来连接的,这时我们就可以使用解释器模式。

注意事项

       解释器模式真的是一个比较少用的模式,因为对它的维护实在是太麻烦了,想象一下,一坨一坨的非终结符解释器,假如不是事先对文法的规则了如指掌,或者是文法特别简单,则很难读懂它的逻辑。解释器模式在实际的系统开发中使用的很少,因为他会引起效率、性能以及维护等问题。

设计模式六大原则(5):迪米特法则

定义:一个对象应该对其他对象保持最少的了解。

问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。

解决方案:尽量降低类与类之间的耦合。

         自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚。无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的。

         迪米特法则又叫最少知道原则,最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲,就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。迪米特法则还有一个更简单的定义:只与直接的朋友通信。首先来解释一下什么是直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等。其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部。

         举一个例子:有一个集团公司,下属单位有分公司和直属部门,现在要求打印出所有下属单位的员工ID。先来看一下违反迪米特法则的设计。

//总公司员工
class Employee{
	private String id;
	public void setId(String id){
		this.id = id;
	}
	public String getId(){
		return id;
	}
}

//分公司员工
class SubEmployee{
	private String id;
	public void setId(String id){
		this.id = id;
	}
	public String getId(){
		return id;
	}
}

class SubCompanyManager{
	public List<SubEmployee> getAllEmployee(){
		List<SubEmployee> list = new ArrayList<SubEmployee>();
		for(int i=0; i<100; i++){
			SubEmployee emp = new SubEmployee();
			//为分公司人员按顺序分配一个ID
			emp.setId("分公司"+i);
			list.add(emp);
		}
		return list;
	}
}

class CompanyManager{

	public List<Employee> getAllEmployee(){
		List<Employee> list = new ArrayList<Employee>();
		for(int i=0; i<30; i++){
			Employee emp = new Employee();
			//为总公司人员按顺序分配一个ID
			emp.setId("总公司"+i);
			list.add(emp);
		}
		return list;
	}
	
	public void printAllEmployee(SubCompanyManager sub){
		List<SubEmployee> list1 = sub.getAllEmployee();
		for(SubEmployee e:list1){
			System.out.println(e.getId());
		}

		List<Employee> list2 = this.getAllEmployee();
		for(Employee e:list2){
			System.out.println(e.getId());
		}
	}
}

public class Client{
	public static void main(String[] args){
		CompanyManager e = new CompanyManager();
		e.printAllEmployee(new SubCompanyManager());
	}
}

        现在这个设计的主要问题出在CompanyManager中,根据迪米特法则,只与直接的朋友发生通信,而SubEmployee类并不是CompanyManager类的直接朋友(以局部变量出现的耦合不属于直接朋友),从逻辑上讲总公司只与他的分公司耦合就行了,与分公司的员工并没有任何联系,这样设计显然是增加了不必要的耦合。按照迪米特法则,应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下:

class SubCompanyManager{
	public List<SubEmployee> getAllEmployee(){
		List<SubEmployee> list = new ArrayList<SubEmployee>();
		for(int i=0; i<100; i++){
			SubEmployee emp = new SubEmployee();
			//为分公司人员按顺序分配一个ID
			emp.setId("分公司"+i);
			list.add(emp);
		}
		return list;
	}
	public void printEmployee(){
		List<SubEmployee> list = this.getAllEmployee();
		for(SubEmployee e:list){
			System.out.println(e.getId());
		}
	}
}

class CompanyManager{
	public List<Employee> getAllEmployee(){
		List<Employee> list = new ArrayList<Employee>();
		for(int i=0; i<30; i++){
			Employee emp = new Employee();
			//为总公司人员按顺序分配一个ID
			emp.setId("总公司"+i);
			list.add(emp);
		}
		return list;
	}
	
	public void printAllEmployee(SubCompanyManager sub){
		sub.printEmployee();
		List<Employee> list2 = this.getAllEmployee();
		for(Employee e:list2){
			System.out.println(e.getId());
		}
	}
}

        修改后,为分公司增加了打印人员ID的方法,总公司直接调用来打印,从而避免了与分公司的员工发生耦合。

        迪米特法则的初衷是降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系。但是凡事都有度,虽然可以避免与非直接的类通信,但是要通信,必然会通过一个“中介”来发生联系,例如本例中,总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。过分的使用迪米特原则,会产生大量这样的中介和传递类,导致系统复杂度变大。所以在采用迪米特法则时要反复权衡,既做到结构清晰,又要高内聚低耦合。

创建类模式总结篇

创建类模式主要关注对象的创建过程,将对象的创建过程进行封装,使客户端可以直接得到对象,而不用去关心如何创建对象。创建类模式有5种,分别是:

为什么需要创建性模式

        首先,在编程中,对象的创建通常是一件比较复杂的事,因为,为了达到降低耦合的目的,我们通常采用面向抽象编程的方式,对象间的关系不会硬编码到类中,而是等到调用的时候再进行组装,这样虽然降低了对象间的耦合,提高了对象复用的可能,但在一定程度上将组装类的任务都交给了最终调用的客户端程序,大大增加了客户端程序的复杂度。采用创建类模式的优点之一就是将组装对象的过程封装到一个单独的类中,这样,既不会增加对象间的耦合,又可以最大限度的减小客户端的负担。

       其次,使用普通的方式创建对象,一般都是返回一个具体的对象,即所谓的面向实现编程,这与设计模式原则是相违背的。采用创建类模式则可以实现面向抽象编程。客户端要求的只是一个抽象的类型,具体返回什么样的对象,由创建者来决定。

       再次,可以对创建对象的过程进行优化,客户端关注的只是得到对象,对对象的创建过程则不关心,因此,创建者可以对创建的过程进行优化,例如在特定条件下,如果使用单例模式或者是使用原型模式,都可以优化系统的性能。

总结

所有的创建类模式本质上都是对对象的创建过程进行封装。

访问者模式讨论篇:java的动态绑定与双分派

java的动态绑定

        所谓的动态绑定就是指程执行期间(而不是在编译期间)判断所引用对象的实际类型,根据其实际的类型调用其相应的方法。java继承体系中的覆盖就是动态绑定的,看一下如下的代码:

class Father {
	public void method(){
		System.out.println("This is Father's method");
	}
}

class Son1 extends Father{
	public void method(){
		System.out.println("This is Son1's method");
	}
}

class Son2 extends Father{
	public void method(){
		System.out.println("This is Son2's method");
	}
}

public class Test {
	public static void main(String[] args){
		Father s1 = new Son1();
		s1.method();
		
		Father s2 = new Son2();
		s2.method();
	}
}

运行结果如下:

This is Son1’s method
This is Son2’s method

       通过运行结果可以看到,尽管我们引用的类型是Father类型的,但是运行时却是调用的它实际类型(也就是Son1和Son2)的方法,这就是动态绑定。在java语言中,继承中的覆盖就是是动态绑定的,当我们用父类引用实例化子类时,会根据引用的实际类型调用相应的方法。

 

java的静态绑定

       相对于动态绑定,静态绑定就是指在编译期就已经确定执行哪一个方法。在java中,方法的重载(方法名相同而参数不同)就是静态绑定的,重载时,执行哪一个方法在编译期就已经确定下来了。看一下代码:

class Father {}
class Son1 extends Father{}
class Son2 extends Father{}

class Execute {
	public void method(Father father){
		System.out.println("This is Father's method");
	}
	
	public void method(Son1 son){
		System.out.println("This is Son1's method");
	}
	
	public void method(Son2 son){
		System.out.println("This is Son2's method");
	}
}

public class Test {
	public static void main(String[] args){
		Father father = new Father();
		Father s1 = new Son1();
		Father s2 = new Son2();

		Execute exe = new Execute();
		exe.method(father);
		exe.method(s1);
		exe.method(s2);
	}
}

运行结果如下:

This is Father’s method
This is Father’s method
This is Father’s method

        在这里,程序在编译的时候就已经确定使用method(Father father)方法了,不管我们在运行的时候传入的实际类型是什么,它永远都只会执行method(Father father)这个方法。也就是说,java的重载是静态绑定的。

 

instanceof操作符与转型

       有时候,我们希望在使用重载的时候,程序能够根据传入参数的实际类型动态地调用相应的方法,也就是说,我们希望java的重载是动态的,而不是静态的。但是由于java的重载不是动态绑定,我们只能通过程序来人为的判断,我们一般会使用instanceof操作符来进行类型的判断。我们要对method(Father father)进行修改,在方法体中判断运行期间的实际类型,修改后的method(Father father)方法如下:

public void method(Father father){
	if(father instanceof Son1){
		method((Son1)father);
	}else if(father instanceof Son2){
		method((Son2)father);
	}else if(father instanceof Father){
		System.out.println("This is Father's method");
	}
}

        请注意,我们必须把判断是否是父类的条件(也就是判断是否为Father类的条件)放到最后,否则将一律会被判断为Father类,达不到我们动态判断的目的。修改代码后,程序就可以动态地根据参数的实际类型来调用相应的方法了。运行结果如下:

This is Father’s method
This is Son1’s method
This is Son2’s method

        但是这种实现方式有一个明显的缺点,它是伪动态的,仍然需要我们来通过程序来判断类型。假如Father有100个子类的话,还是这样来实现显然是不合适的。必须通过其他更好的方式实现才行,我们可以使用双分派方式来实现动态绑定。

      

用双分派实现动态绑定

        首先,什么是双分派?还记得23种设计模式(9):访问者模式中一开始举的例子吗?

        类A中的方法method1和method2的区别就是,method2是双分派。我们可以看一下java双分派的特点:首先要有一个访问类B,类B提供一个showA(A a) 方法,在方法中,调用类A的method1方法,然后类A的method2方法中调用类B的showA方法并将自己作为参数传给showA。双分派的核心就是这个this对象。说到这里,我们已经明白双分派是怎么回事了,但是它有什么效果呢?就是可以实现方法的动态绑定,我们可以对上面的程序进行修改,代码如下:

class Father {
	public void accept(Execute exe){
		exe.method(this);
	}
}
class Son1 extends Father{
	public void accept(Execute exe){
		exe.method(this);
	}
}
class Son2 extends Father{
	public void accept(Execute exe){
		exe.method(this);
	}
}

class Execute {
	public void method(Father father){
		System.out.println("This is Father's method");
	}
	
	public void method(Son1 son){
		System.out.println("This is Son1's method");
	}
	
	public void method(Son2 son){
		System.out.println("This is Son2's method");
	}
}

public class Test {
	public static void main(String[] args){
		Father father = new Father();
		Father s1 = new Son1();
		Father s2 = new Son2();

		Execute exe = new Execute();
		father.accept(exe);
		s1.accept(exe);
		s2.accept(exe);
	}
}

        可以看到我们修改的地方,在Father,Son1,Son2中分别加入一个双分派的方法。调用的时候,原本是调用Execute的method方法,现在改为调用Father的accept方法。运行结果如下:

This is Father’s method
This is Son1’s method
This is Son2’s method

        运行结果符合我们的预期,实现了动态绑定。双分派实现动态绑定的本质,就是在重载方法委派的前面加上了继承体系中覆盖的环节,由于覆盖是动态的,所以重载就是动态的了,与使用instanceof操作符的效果是一样的(用instanceof操作符可以实现重载方法动态绑定的原因也是因为instanceof操作符是动态的)。但是与使用instanceof操作符实现动态绑定相比,双分派方式的可扩展性要好的多。