设计模式：策略模式（Strategy Pattern）

定义

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

类型

行为类模式

类图

Strategy Pattern

策略模式的结构

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

代码实现

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
31
32
33
34
35
36
37
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个，就比较令人头疼了。
  • 违反迪米特法则：必须对客户端（调用者）暴露所有的策略类，因为使用哪种策略是由客户端来决定的，因此，客户端应该知道有什么策略，并且了解各种策略之间的区别，否则，后果很严重。例如，有一个排序算法的策略模式，提供了快速排序、冒泡排序、选择排序这三种算法，客户端在使用这些算法之前，是不是先要明白这三种算法的适用情况？再比如，客户端要使用一个容器，有链表实现的，也有数组实现的，客户端是不是也要明白链表和数组有什么区别？就这一点来说是有悖于迪米特法则的。

适用场景

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

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

评论和共享

设计模式：责任链模式（Chain of Responsibility Pattern）

定义

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

类型

行为类模式

类图

Chain Of Responsibility

##　责任连模式的结构

  • 抽象处理类：抽象处理类中主要包含一个指向下一处理类的成员变量nextHandler和一个处理请求的方法handRequest，handRequest方法的主要主要思想是，如果满足处理的条件，则有本处理类来进行处理，否则由nextHandler来处理。
  • 具体处理类：具体处理类主要是对具体的处理逻辑和处理的适用条件进行实现。

代码实现

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
class Level {  
    private int level = 0;  
    public Level(int level){  
        this.level = level;  
    };  

    public boolean above(Level level){  
        if(this.level >= level.level){  
            return true;  
        }  
        return false;  
    }  
}  

class Request {  
    Level level;  
    public Request(Level level){  
        this.level = level;  
    }  

    public Level getLevel(){  
        return level;  
    }  
}  

class Response {  

}  

abstract class Handler {  
    private Handler nextHandler;      
    public final Response handleRequest(Request request){  
        Response response = null;  

        if(this.getHandlerLevel().above(request.getLevel())){  
            response = this.response(request);  
        }else{  
            if(this.nextHandler != null){  
                this.nextHandler.handleRequest(request);  
            }else{  
                System.out.println("-----没有合适的处理器-----");  
            }  
        }  
        return response;  
    }  
    public void setNextHandler(Handler handler){  
        this.nextHandler = handler;  
    }  
    protected abstract Level getHandlerLevel();  
    public abstract Response response(Request request);  
}  

class ConcreteHandler1 extends Handler {  
    protected Level getHandlerLevel() {  
        return new Level(1);  
    }  
    public Response response(Request request) {  
        System.out.println("-----请求由处理器1进行处理-----");  
        return null;  
    }  
}  

class ConcreteHandler2 extends Handler {  
    protected Level getHandlerLevel() {  
        return new Level(3);  
    }  
    public Response response(Request request) {  
        System.out.println("-----请求由处理器2进行处理-----");  
        return null;  
    }  
}  

class ConcreteHandler3 extends Handler {  
    protected Level getHandlerLevel() {  
        return new Level(5);  
    }  
    public Response response(Request request) {  
        System.out.println("-----请求由处理器3进行处理-----");  
        return null;  
    }  
}  

public class Client {  
    public static void main(String[] args){  
        Handler handler1 = new ConcreteHandler1();  
        Handler handler2 = new ConcreteHandler2();  
        Handler handler3 = new ConcreteHandler3();  

        handler1.setNextHandler(handler2);  
        handler2.setNextHandler(handler3);  

        Response response = handler1.handleRequest(new Request(new Level(4)));  
    }  
}

优点

责任链模式与if…else…相比，他的耦合性要低一些，因为它把条件判定都分散到了各个处理类中，并且这些处理类的优先处理顺序可以随意设定

缺点

在找到正确的处理类之前，所有的判定条件都要被执行一遍，当责任链比较长时，性能问题比较严重。

责任链模式的适用场景

就像开始的例子那样，假如使用if…else…语句来组织一个责任链时感到力不从心，代码看上去很糟糕时，就可以使用责任链模式来进行重构。

总结

责任链模式其实就是一个灵活版的if…else…语句，它就是将这些判定条件的语句放到了各个处理类中，这样做的优点是比较灵活了，但同样也带来了风险，比如设置处理类前后关系时，一定要特别仔细，搞对处理类前后逻辑的条件判断关系，并且注意不要在链中出现循环引用的问题。

责任连模式常常会和模板方法一起使用

评论和共享

设计模式：命令模式（Command Pattern）

定义

将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

类型

行为类模式

类图

Command Pattern

命令模式的结构

  • Command类：是一个抽象类，类中对需要执行的命令进行声明，一般来说要对外公布一个execute方法用来执行命令。
  • ConcreteCommand类：Command类的实现类，对抽象类中声明的方法进行实现。
  • Client类：最终的客户端调用类。
  • Invoker类：调用者，负责调用命令。
  • Receiver类：接收者，负责接收命令并且执行命令。

代码实现

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
31
32
33
34
35
36
37
38
39
40
41
42
43
class Invoker {  
    private Command command;  
    public void setCommand(Command command) {  
        this.command = command;  
    }  
    public void action(){  
        this.command.execute();  
    }  
}  

abstract class Command {  
    public abstract void execute();  
}  

class ConcreteCommand extends Command {  
    private Receiver receiver;  
    public ConcreteCommand(Receiver receiver){  
        this.receiver = receiver;  
    }  
    public void execute() {  
        this.receiver.doSomething();  
    }  
}  

class Receiver {  
    public void doSomething(){  
        System.out.println("接受者-业务逻辑处理");  
    }  
}  

public class Client {  
    public static void main(String[] args){  
        Receiver receiver = new Receiver();  
        Command command = new ConcreteCommand(receiver);  
        //客户端直接执行具体命令方式（此方式与类图相符）  
        command.execute();  

        //客户端通过调用者来执行命令  
        Invoker invoker = new Invoker();  
        invoker.setCommand(command);  
        invoker.action();  
    }  
}

命令模式的优缺点

首先，命令模式的封装性很好：每个命令都被封装起来，对于客户端来说，需要什么功能就去调用相应的命令，而无需知道命令具体是怎么执行的。比如有一组文件操作的命令：新建文件、复制文件、删除文件。如果把这三个操作都封装成一个命令类，客户端只需要知道有这三个命令类即可，至于命令类中封装好的逻辑，客户端则无需知道。

其次，命令模式的扩展性很好，在命令模式中，在接收者类中一般会对操作进行最基本的封装，命令类则通过对这些基本的操作进行二次封装，当增加新命令的时候，对命令类的编写一般不是从零开始的，有大量的接收者类可供调用，也有大量的命令类可供调用，代码的复用性很好。比如，文件的操作中，我们需要增加一个剪切文件的命令，则只需要把复制文件和删除文件这两个命令组合一下就行了，非常方便。

最后说一下命令模式的缺点，那就是命令如果很多，开发起来就要头疼了。特别是很多简单的命令，实现起来就几行代码的事，而使用命令模式的话，不用管命令多简单，都需要写一个命令类来封装。

命令模式的适用场景

对于大多数请求-响应模式的功能，比较适合使用命令模式，正如命令模式定义说的那样，命令模式对实现记录日志、撤销操作等功能比较方便。

总结

对于一个场合到底用不用模式，这对所有的开发人员来说都是一个很纠结的问题。有时候，因为预见到需求上会发生的某些变化，为了系统的灵活性和可扩展性而使用了某种设计模式，但这个预见的需求偏偏没有，相反，没预见到的需求倒是来了不少，导致在修改代码的时候，使用的设计模式反而起了相反的作用，以至于整个项目组怨声载道。这样的例子，我相信每个程序设计者都遇到过。所以，基于敏捷开发的原则，我们在设计程序的时候，如果按照目前的需求，不使用某种模式也能很好地解决，那么我们就不要引入它，因为要引入一种设计模式并不困难，我们大可以在真正需要用到的时候再对系统进行一下，引入这个设计模式。

拿命令模式来说吧，我们开发中，请求-响应模式的功能非常常见，一般来说，我们会把对请求的响应操作封装到一个方法中，这个封装的方法可以称之为命令，但不是命令模式。到底要不要把这种设计上升到模式的高度就要另行考虑了，因为，如果使用命令模式，就要引入调用者、接收者两个角色，原本放在一处的逻辑分散到了三个类中，设计时，必须考虑这样的代价是否值得。

感觉 Redux 有借鉴命令模式的思想

评论和共享

设计模式：备忘录模式（Memento Pattern）

定义

将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

类型

行为类模式

类图

Memento Pattern

备忘录模式的结构

  • 发起人：记录当前时刻的内部状态，负责定义哪些属于备份范围的状态，负责创建和恢复备忘录数据。
  • 备忘录：负责存储发起人对象的内部状态，在需要的时候提供发起人需要的内部状态。
  • 管理角色：对备忘录进行管理，保存和提供备忘录。

代码实现

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
class Originator {  
    private String state = "";  

    public String getState() {  
        return state;  
    }  
    public void setState(String state) {  
        this.state = state;  
    }  
    public Memento createMemento(){  
        return new Memento(this.state);  
    }  
    public void restoreMemento(Memento memento){  
        this.setState(memento.getState());  
    }  
}  

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;  
    }  
}  
class Caretaker {  
    private Memento memento;  
    public Memento getMemento(){  
        return memento;  
    }  
    public void setMemento(Memento memento){  
        this.memento = memento;  
    }  
}  
public class Client {  
    public static void main(String[] args){  
        Originator originator = new Originator();  
        originator.setState("状态1");  
        System.out.println("初始状态:"+originator.getState());  
        Caretaker caretaker = new Caretaker();  
        caretaker.setMemento(originator.createMemento());  
        originator.setState("状态2");  
        System.out.println("改变后状态:"+originator.getState());  
        originator.restoreMemento(caretaker.getMemento());  
        System.out.println("恢复后状态:"+originator.getState());  
    }  
}

备忘录模式的优点

当发起人角色中的状态改变时，有可能这是个错误的改变，我们使用备忘录模式就可以把这个错误的改变还原。

备份的状态是保存在发起人角色之外的，这样，发起人角色就不需要对各个备份的状态进行管理。

备忘录模式的缺点

在实际应用中，备忘录模式都是多状态和多备份的，发起人角色的状态需要存储到备忘录对象中，对资源的消耗是比较严重的。

感受

和命令模式可以完成相同的事情，备份和还原，但是两者又有所不同，命令模式更加偏向于记录变化的部分，而备忘录模式是备份整个状态

评论和共享

设计模式：访问者模式（Visitor Pattern）

定义

封装某些作用于某种数据结构中各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

类型

行为类模式

类图

Visitor Pattern

要素

  • 抽象访问者：抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是visit方法中的参数定义哪些对象是可以被访问的。
  • 访问者：实现抽象访问者所声明的方法，它影响到访问者访问到一个类后该干什么，要做什么事情。
  • 抽象元素类：接口或者抽象类，声明接受哪一类访问者访问，程序上是通过accept方法中的参数来定义的。抽象元素一般有两类方法，一部分是本身的业务逻辑，另外就是允许接收哪类访问者来访问。
  • 元素类：实现抽象元素类所声明的accept方法，通常都是visitor.visit(this)，基本上已经形成一种定式了。
  • 结构对象：一个元素的容器，一般包含一个容纳多个不同类、不同接口的容器，如List、Set、Map等，在项目中一般很少抽象出这个角色。

代码实现

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
abstract class Element {  
    public abstract void accept(IVisitor visitor);  
    public abstract void doSomething();  
}  

interface IVisitor {  
    public void visit(ConcreteElement1 el1);  
    public void visit(ConcreteElement2 el2);  
}  

class ConcreteElement1 extends Element {  
    public void doSomething(){  
        System.out.println("这是元素1");  
    }  

    public void accept(IVisitor visitor) {  
        visitor.visit(this);  
    }  
}  

class ConcreteElement2 extends Element {  
    public void doSomething(){  
        System.out.println("这是元素2");  
    }  

    public void accept(IVisitor visitor) {  
        visitor.visit(this);  
    }  
}  
class Visitor implements IVisitor {  

    public void visit(ConcreteElement1 el1) {  
        el1.doSomething();  
    }  

    public void visit(ConcreteElement2 el2) {  
        el2.doSomething();  
    }  
}  

class ObjectStruture {  
    public static List<Element> getList(){  
        List<Element> list = new ArrayList<Element>();  
        Random ran = new Random();  
        for(int i=0; i<10; i++){  
            int a = ran.nextInt(100);  
            if(a>50){  
                list.add(new ConcreteElement1());  
            }else{  
                list.add(new ConcreteElement2());  
            }  
        }  
        return list;  
    }  
}  

public class Client {  
    public static void main(String[] args){  
        List<Element> list = ObjectStruture.getList();  
        for(Element e: list){  
            e.accept(new Visitor());  
        }  
    }  
}

##　访问者模式的优点

  • 符合单一职责原则：凡是适用访问者模式的场景中，元素类中需要封装在访问者中的操作必定是与元素类本身关系不大且是易变的操作，使用访问者模式一方面符合单一职责原则，另一方面，因为被封装的操作通常来说都是易变的，所以当发生变化时，就可以在不改变元素类本身的前提下，实现对变化部分的扩展。
  • 扩展性良好：元素类可以通过接受不同的访问者来实现对不同操作的扩展。

缺点

  • 增加新的元素类比较困难：通过访问者模式的代码可以看到，在访问者类中，每一个元素类都有它对应的处理方法，也就是说，每增加一个元素类都需要修改访问者类（也包括访问者类的子类或者实现类），修改起来相当麻烦。也就是说，在元素类数目不确定的情况下，应该慎用访问者模式。所以，访问者模式比较适用于对已有功能的重构，比如说，一个项目的基本功能已经确定下来，元素类的数据已经基本确定下来不会变了，会变的只是这些元素内的相关操作，这时候，我们可以使用访问者模式对原有的代码进行重构一遍，这样一来，就可以在不修改各个元素类的情况下，对原有功能进行修改。

访问者模式的适用场景

假如一个对象中存在着一些与本对象不相干（或者关系较弱）的操作，为了避免这些操作污染这个对象，则可以使用访问者模式来把这些操作封装到访问者中去。

假如一组对象中，存在着相似的操作，为了避免出现大量重复的代码，也可以将这些重复的操作封装到访问者中去。

评论和共享

设计模式：观察者模式（Observer Pattern）

定义

定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。

类型

行为类模式

类图

Observer Pattern

代码实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
abstract class Subject {  
    private Vector<Observer> obs = new Vector<Observer>();  

    public void addObserver(Observer obs){  
        this.obs.add(obs);  
    }  
    public void delObserver(Observer obs){  
        this.obs.remove(obs);  
    }  
    protected void notifyObserver(){  
        for(Observer o: obs){  
            o.update();  
        }  
    }  
    public abstract void doSomething();  
}

观察者模式的优点

  • 观察者与被观察者之间是属于轻度的关联关系，并且是抽象耦合的，这样，对于两者来说都比较容易进行扩展。
  • 观察者模式是一种常用的触发机制，它形成一条触发链，依次对各个观察者的方法进行处理。但同时，这也算是观察者模式一个缺点，由于是链式触发，当观察者比较多的时候，性能问题是比较令人担忧的。并且，在链式结构中，比较容易出现循环引用的错误，造成系统假死。
    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

    class ConcreteSubject extends Subject {  
        public void doSomething(){  
            System.out.println("被观察者事件反生");  
            this.notifyObserver();  
        }  
    }  
    interface Observer {  
        public void update();  
    }  
    class ConcreteObserver1 implements Observer {  
        public void update() {  
            System.out.println("观察者1收到信息，并进行处理。");  
        }  
    }  
    class ConcreteObserver2 implements Observer {  
        public void update() {  
            System.out.println("观察者2收到信息，并进行处理。");  
        }  
    }  

    public class Client {  
        public static void main(String[] args){  
            Subject sub = new ConcreteSubject();  
            sub.addObserver(new ConcreteObserver1()); //添加观察者1  
            sub.addObserver(new ConcreteObserver2()); //添加观察者2  
            sub.doSomething();  
        }  
    }

##运行结果

1
2
3
被观察者事件反生
观察者1收到信息，并进行处理。
观察者2收到信息，并进行处理。

观察者模式的优点

观察者与被观察者之间是属于轻度的关联关系，并且是抽象耦合的，这样，对于两者来说都比较容易进行扩展。

观察者模式是一种常用的触发机制，它形成一条触发链，依次对各个观察者的方法进行处理。但同时，这也算是观察者模式一个缺点，由于是链式触发，当观察者比较多的时候，性能问题是比较令人担忧的。并且，在链式结构中，比较容易出现循环引用的错误，造成系统假死。

评论和共享

设计模式：中介者模式（Mediator Pattern）

定义

用一个中介者对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使耦合松散，而且可以独立地改变它们之间的交互。

类型

行为类模式

类图

Mediator Pattern

为什么要使用中介者模式

不使用中介者，各个类的关系就像 p2p 网络，是一种星形的的，采用了中介者模式后，就像变成了 CS 架构。任何一个类的变动，只会影响的类本身，以及中介者，这样就减小了系统的耦合

例子

我们使用一个例子来说明一下什么是同事类：有两个类A和B，类中各有一个数字，并且要保证类B中的数字永远是类A中数字的100倍。也就是说，当修改类A的数时，将这个数字乘以100赋给类B，而修改类B时，要将数除以100赋给类A。类A类B互相影响，就称为同事类。代码如下：

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
abstract class AbstractColleague {  
    protected int number;  

    public int getNumber() {  
        return number;  
    }  

    public void setNumber(int number){  
        this.number = number;  
    }  
    //抽象方法，修改数字时同时修改关联对象  
    public abstract void setNumber(int number, AbstractColleague coll);  
}  

class ColleagueA extends AbstractColleague{  
    public void setNumber(int number, AbstractColleague coll) {  
        this.number = number;  
        coll.setNumber(number*100);  
    }  
}  

class ColleagueB extends AbstractColleague{  

    public void setNumber(int number, AbstractColleague coll) {  
        this.number = number;  
        coll.setNumber(number/100);  
    }  
}  

public class Client {  
    public static void main(String[] args){  

        AbstractColleague collA = new ColleagueA();  
        AbstractColleague collB = new ColleagueB();  

        System.out.println("==========设置A影响B==========");  
        collA.setNumber(1288, collB);  
        System.out.println("collA的number值："+collA.getNumber());  
        System.out.println("collB的number值："+collB.getNumber());  

        System.out.println("==========设置B影响A==========");  
        collB.setNumber(87635, collA);  
        System.out.println("collB的number值："+collB.getNumber());  
        System.out.println("collA的number值："+collA.getNumber());  
    }  
}

假如我们要使用中介者模式，类A类B之间则不可以直接关联，他们之间必须要通过一个中介者来达到关联的目的。

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
abstract class AbstractColleague {  
    protected int number;  

    public int getNumber() {  
        return number;  
    }  

    public void setNumber(int number){  
        this.number = number;  
    }  
    //注意这里的参数不再是同事类，而是一个中介者  
    public abstract void setNumber(int number, AbstractMediator am);  
}  

class ColleagueA extends AbstractColleague{  

    public void setNumber(int number, AbstractMediator am) {  
        this.number = number;  
        am.AaffectB();  
    }  
}  

class ColleagueB extends AbstractColleague{  

    @Override  
    public void setNumber(int number, AbstractMediator am) {  
        this.number = number;  
        am.BaffectA();  
    }  
}  

abstract class AbstractMediator {  
    protected AbstractColleague A;  
    protected AbstractColleague B;  

    public AbstractMediator(AbstractColleague a, AbstractColleague b) {  
        A = a;  
        B = b;  
    }  

    public abstract void AaffectB();  

    public abstract void BaffectA();  

}  
class Mediator extends AbstractMediator {  

    public Mediator(AbstractColleague a, AbstractColleague b) {  
        super(a, b);  
    }  

    //处理A对B的影响  
    public void AaffectB() {  
        int number = A.getNumber();  
        B.setNumber(number*100);  
    }  

    //处理B对A的影响  
    public void BaffectA() {  
        int number = B.getNumber();  
        A.setNumber(number/100);  
    }  
}  

public class Client {  
    public static void main(String[] args){  
        AbstractColleague collA = new ColleagueA();  
        AbstractColleague collB = new ColleagueB();  

        AbstractMediator am = new Mediator(collA, collB);  

        System.out.println("==========通过设置A影响B==========");  
        collA.setNumber(1000, am);  
        System.out.println("collA的number值为："+collA.getNumber());  
        System.out.println("collB的number值为A的10倍："+collB.getNumber());  

        System.out.println("==========通过设置B影响A==========");  
        collB.setNumber(1000, am);  
        System.out.println("collB的number值为："+collB.getNumber());  
        System.out.println("collA的number值为B的0.1倍："+collA.getNumber());  

    }  
}

虽然代码比较长，但是还是比较容易理解的，其实就是把原来处理对象关系的代码重新封装到一个中介类中，通过这个中介类来处理对象间的关系。

中介者模式的优点

  • 适当地使用中介者模式可以避免同事类之间的过度耦合，使得各同事类之间可以相对独立地使用。
  • 使用中介者模式可以将对象间一对多的关联转变为一对一的关联，使对象间的关系易于理解和维护。
  • 使用中介者模式可以将对象的行为和协作进行抽象，能够比较灵活的处理对象间的相互作用。

适用场景

在面向对象编程中，一个类必然会与其他的类发生依赖关系，完全独立的类是没有意义的。一个类同时依赖多个类的情况也相当普遍，既然存在这样的情况，说明，一对多的依赖关系有它的合理性，适当的使用中介者模式可以使原本凌乱的对象关系清晰，但是如果滥用，则可能会带来反的效果。一般来说，只有对于那种同事类之间是网状结构的关系，才会考虑使用中介者模式。可以将网状结构变为星状结构，使同事类之间的关系变的清晰一些。

中介者模式是一种比较常用的模式，也是一种比较容易被滥用的模式。对于大多数的情况，同事类之间的关系不会复杂到混乱不堪的网状结构，因此，大多数情况下，将对象间的依赖关系封装的同事类内部就可以的，没有必要非引入中介者模式。滥用中介者模式，只会让事情变的更复杂。

评论和共享

设计模式：模板方法模式（Template Method Pattem）

定义

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

类型

行为类模式

类图

Template Method Pattern

模版方法是编程中一个经常用到的模式。

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
//抽象模板类
public abstract class AbstractClass {
    //基本方法，不同实现
    protected abstract void doSomething();
    //模板方法，相同
    public void templateMethod() {
        //调用基本方法，完成相关逻辑
        this.doSomething();
    }
}

//具体模板类
public class ConcreateClass1 extends AbstractClass {
    protected void doSomething() {
        //业务逻辑
    }
}
//省略 ConcreateClass2

public class Client {
    public static void main(String[] args) {
        AbstractClass class1 = new ConcreateClass1();
        AbstractClass class2 = new ConcreateClass2();

        class1.templateMethod();
        class2.templateMethod();
    }
}

模板方法优点

  • 封装不变部分，拓展可变部分
  • 提取公共部分代码，便于维护
  • 行为由父类控制，子类实现，符合开闭原则

模板方法缺点

按照习惯，抽象类负责声明最抽象，最一般的事物属性和方法，实现类完成具体的事物属性和方法。但是模板类却颠倒这个顺序，抽象类定义了部分抽象方法，由子类实现，子类执行的结果影响父类的结果，在复杂项目中带来了代码阅读的难度，让新手不适应。

使用场景

  • 多个子类有公有的方法，并且逻辑基本相同
  • 重要，复杂的算法，可以吧核心算法设计为模板方法，周边的相关细节功能则由各个子类实现
  • 重构时，把相同代码收取到父类中，让后通过钩子函数约束其行为。

评论和共享

设计模式：创建类模式总结

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

  • 单例模式：用于得到内存中的唯一对象。
  • 工厂方法模式：用于创建复杂对象。
  • 抽象工厂模式：用于创建一组相关或相互依赖的复杂对象。
  • 建造者模式：用于创建模块化的更加复杂的对象。
  • 原型模式：用于得到一个对象的拷贝。

为什么需要创建性模式

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

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

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

总结

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

评论和共享

设计模式：原形模式（Prototype Pattern）

定义

用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。

类型

创建类模式

类图

Prototype Pattern

原型模式主要用于对象的复制，它的核心是就是类图中的原型类Prototype。Prototype类需要具备以下两个条件：

  • 实现 Cloneable 接口。在java语言有一个Cloneable 接口，它的作用只有一个，就是在运行时通知虚拟机可以安全地在实现了此接口的类上使用 clone 方法。在java虚拟机中，只有实现了这个接口的类才可以被拷贝，否则在运行时会出 CloneNotSupportedException异常。
  • 重写 Object 类中的 clone 方法。Java中，所有类的父类都是 Object 类，Object 类中有一个 clone 方法，作用是返回对象的一个拷贝，但是其作用域 protected 类型的，一般的类无法调用，因此，Prototype 类需要将 clone 方法的作用域修改为 public 类型。

原型模式是一种比较简单的模式，也非常容易理解，实现一个接口，重写一个方法即完成了原型模式。在实际应用中，原型模式很少单独出现。经常与其他模式混用，他的原型类 Prototype 也常用抽象类来替代。

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
class Prototype implements Cloneable {  
    public Prototype clone(){
        Prototype prototype = null;  
        try{  
            prototype = (Prototype)super.clone();  
        }catch(CloneNotSupportedException e){  
            e.printStackTrace();  
        }  
        return prototype;   
    }  
}  

class ConcretePrototype extends Prototype{  
    public void show(){  
        System.out.println("原型模式实现类");  
    }  
}  

public class Client {  
    public static void main(String[] args){  
        ConcretePrototype cp = new ConcretePrototype();  
        for(int i=0; i< 10; i++){  
            ConcretePrototype clonecp = (ConcretePrototype)cp.clone();  
            clonecp.show();  
        }
    }
}

原型模式的优点及适用场景

使用原型模式创建对象比直接new一个对象在性能上要好的多，因为Object类的clone方法是一个本地方法，它直接操作内存中的二进制流，特别是复制大对象时，性能的差别非常明显。

使用原型模式的另一个好处是简化对象的创建，使得创建对象就像我们在编辑文档时的复制粘贴一样简单。

因为以上优点，所以在需要重复地创建相似对象时可以考虑使用原型模式。比如需要在一个循环体内创建对象，假如对象创建过程比较复杂或者循环次数很多的话，使用原型模式不但可以简化创建过程，而且可以使系统的整体性能提高很多。

原型模式的注意事项

  • 使用原型模式复制对象不会调用类的构造方法。因为对象的复制是通过调用Object类的clone方法来完成的，它直接在内存中复制数据，因此不会调用到类的构造方法。不但构造方法中的代码不会执行，甚至连访问权限都对原型模式无效。还记得单例模式吗？单例模式中，只要将构造方法的访问权限设置为private型，就可以实现单例。但是clone方法直接无视构造方法的权限，所以，单例模式与原型模式是冲突的，在使用时要特别注意。
  • 深拷贝与浅拷贝。Object类的clone方法只会拷贝对象中的基本的数据类型，对于数组、容器对象、引用对象等都不会拷贝，这就是浅拷贝。如果要实现深拷贝，必须将原型模式中的数组、容器对象、引用对象等另行拷贝。例如：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    public class Prototype implements Cloneable {  
        private ArrayList list = new ArrayList();  
        public Prototype clone(){  
            Prototype prototype = null;  
            try{  
                prototype = (Prototype)super.clone();  
                prototype.list = (ArrayList) this.list.clone();  
            }catch(CloneNotSupportedException e){  
                e.printStackTrace();  
            }  
            return prototype;   
        }  
    }

由于ArrayList不是基本类型，所以成员变量list，不会被拷贝，需要我们自己实现深拷贝，幸运的是Java提供的大部分的容器类都实现了Cloneable接口。所以实现深拷贝并不是特别困难。

PS：深拷贝与浅拷贝问题中，会发生深拷贝的有java中的8中基本类型以及他们的封装类型，另外还有String类型。其余的都是浅拷贝。

评论和共享

作者的图片

Archie Shi

Nothing to say


Front-End Development Engineer