设计模式：建造者模式（Builder Pattern）

定义

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

类型

创建类模式

类图

Builder 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
52
53
class Product {
    private String name;
    private String type;
    public void showProduct(){
        System.out.println("名称："+name);
        System.out.println("型号："+type);
    }
    public void setName(String name) {  
        this.name = name;  
    }  
    public void setType(String type) {  
        this.type = type;  
    }  
}  

abstract class Builder {  
    public abstract void setPart(String arg1, String arg2);  
    public abstract Product getProduct();  
}  
class ConcreteBuilder extends Builder {  
    private Product product = new Product();  

    public Product getProduct() {  
        return product;  
    }  

    public void setPart(String arg1, String arg2) {  
        product.setName(arg1);  
        product.setType(arg2);  
    }  
}  

public class Director {  
    private Builder builder = new ConcreteBuilder();  
    public Product getAProduct(){  
        builder.setPart("宝马汽车","X7");  
        return builder.getProduct();  
    }  
    public Product getBProduct(){  
        builder.setPart("奥迪汽车","Q5");  
        return builder.getProduct();  
    }  
}  
public class Client {  
    public static void main(String[] args){  
        Director director = new Director();  
        Product product1 = director.getAProduct();  
        product1.showProduct();  

        Product product2 = director.getBProduct();  
        product2.showProduct();  
    }  
}

建造者模式的优点

  • 首先，建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在导演类中对整体而言可以取得比较好的稳定性。
  • 其次，建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。

建造者模式与工厂模式的区别

  • 我们可以看到，建造者模式与工厂模式是极为相似的，总体上，建造者模式仅仅只比工厂模式多了一个“导演类”的角色。在建造者模式的类图中，假如把这个导演类看做是最终调用的客户端，那么图中剩余的部分就可以看作是一个简单的工厂模式了。
  • 与工厂模式相比，建造者模式一般用来创建更为复杂的对象，因为对象的创建过程更为复杂，因此将对象的创建过程独立出来组成一个新的类——导演类。也就是说，工厂模式是将对象的全部创建过程封装在工厂类中，由工厂类向客户端提供最终的产品；而建造者模式中，建造者类一般只提供产品类中各个组件的建造，而将具体建造过程交付给导演类。由导演类负责将各个组件按照特定的规则组建为产品，然后将组建好的产品交付给客户端。

总结

  • 建造者模式与工厂模式类似，他们都是建造者模式，适用的场景也很相似。一般来说，如果产品的建造很复杂，那么请用工厂模式；如果产品的建造更复杂，那么请用建造者模式。

评论和共享

设计模式：抽象工厂模式（Abstract Factory Pattern）

定义

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

类型

创建类模式

类图

Abstract Factory Pattern

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

  • 抽象工厂模式是工厂方法模式的升级版本，他用来创建一组相关或者相互依赖的对象。他与工厂方法模式的区别就在于，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则是针对的多个产品等级结构。在编程中，通常一个产品结构，表现为一个接口或者抽象类，也就是说，工厂方法模式提供的所有产品都是衍生自同一个接口或抽象类，而抽象工厂模式所提供的产品则是衍生自不同的接口或抽象类。
  • 在抽象工厂模式中，有一个产品族的概念：所谓的产品族，是指位于不同产品等级结构中功能相关联的产品组成的家族。抽象工厂模式所提供的一系列产品就组成一个产品族；而工厂方法提供的一系列产品称为一个等级结构。我们依然拿生产汽车的例子来说明他们之间的区别。

car

在上面的类图中，两厢车和三厢车称为两个不同的等级结构；而2.0排量车和2.4排量车则称为两个不同的产品族。

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
public abstract class AbstractProductA {
    //每个产品共有的方法
    public void shareMethod(){}
    //每个产品不同的实现
    public abstract void doSomething();
}

public class ProductA1 extends AbstractProductA {
    public void doSomething() {
        System.out.println("产品A1的实现方法")
    }
}

//产品A2,B1,B2 类似，此处省略

//抽象工厂类
public abstract class AbstractCreator {
    public abstract AbstractProductA createProductA();
    public abstract AbstractProductB createProductB();
}

//产品级1的实现类 产品级2类似，此处省略
public class Creator1 extends AbstractCreator {
    public abstract AbstractProductA createProductA() {
        return new ProductA1();
    }
    public abstract AbstractProductB createProductB() {
        return new ProductB1();
    }
}

//客户端代码
public class Client {
    public static void main(String[] args) {
        AbstractCreator creator1 = new Creator1();
        AbstractCreator creator2 = new Creator2();

        AbstractProductA a1 = creator1.createProductA();
        AbstractProductA b2 = creator2.createProductB();
        //...
    }
}

抽象工厂模式的优点

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

抽象工厂模式的缺点

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

适用场景

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

总结

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

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

评论和共享

设计模式：工厂方法模式（Factory Method Pattern）

设计模式：工厂方法模式（Factory Method Pattern）

定义

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

类型

创建类模式

类图

Factory 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
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();  
    }
}

典型应用

汽车由发动机、轮、底盘组成，现在需要组装一辆车交给调用者。假如不使用工厂模式，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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();  
    }  
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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();  
    }  
}

适用场景

  • 首先，作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过new就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。
  • 其次，工厂模式是一种典型的解耦模式，迪米特法则在工厂模式中表现的尤为明显。假如调用者自己组装产品需要增加依赖关系时，可以考虑使用工厂模式。将会大大降低对象之间的耦合度。
  • 再次，由于工厂模式是依靠抽象架构的，它把实例化产品的任务交由实现类完成，扩展性比较好。也就是说，当需要系统有比较好的扩展性时，可以考虑工厂模式，不同的产品用不同的实现工厂来组装。

优点

  • 可以使代码结构清晰，有效地封装变化。
  • 对调用者屏蔽具体的产品类
  • 降低耦合度

评论和共享

设计模式：单例模式（Singleton Pattern）

定义

确保一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

类型

创建类模式

类图

Singleton

要素

  • 私有的构造方法
  • 指向自己实例的私有静态引用
  • 以自己实例为返回值的静态的公有的方法

饿汉式单例

1
2
3
4
5
6
7
public class Singleton {  
    private static Singleton singleton = new Singleton();  
    private Singleton(){}  
    public static Singleton getInstance(){  
        return singleton;  
    }  
}

懒汉式单例

1
2
3
4
5
6
7
8
9
10
11
public class Singleton {  
    private static Singleton singleton;  
    private Singleton(){}  

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

单例模式的优点

  • 在内存中只有一个对象，节省内存空间。
  • 避免频繁的创建销毁对象，可以提高性能。
  • 避免对共享资源的多重占用。
  • 可以全局访问。

适用场景

由于单例模式的以上优点，所以是编程中用的比较多的一种设计模式。我总结了一下我所知道的适合使用单例模式的场景：

  • 需要频繁实例化然后销毁的对象。
  • 创建对象时耗时过多或者耗资源过多，但又经常用到的对象。
  • 有状态的工具类对象。
  • 频繁访问数据库或文件的对象。
  • 以及其他我没用过的所有要求只有一个对象的场景。

单例模式注意事项

  • 只能使用单例类提供的方法得到单例对象，不要使用反射，否则将会实例化一个新对象。
  • 不要做断开单例类对象与类中静态引用的危险操作。
  • 多线程使用单例使用共享资源时，注意线程安全问题。

评论和共享

设计原则：迪米特法则（LoD）

迪米特法则

迪米特法则（Law of Demeter）简称LoD

解释

一个对象应该对其他对象有最少的了解。

总结

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

评论和共享

设计原则：开闭原则（OCP）

开闭原则

开闭原则（Open Closed Principle）简称OCP

解释

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

总结

当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

评论和共享

设计原则：依赖倒置原则（DIP）

依赖倒置原则

依赖倒置原则（Dependence Inversion Principle）简称DIP

##　解释
程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

  • 高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
  • 抽象不应该依赖于具体实现，具体实现应该依赖于抽象。

例如：
母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Book{  
    public String getContent(){  
        return "很久很久以前有一个阿拉伯的故事……";  
    }  
}  

class Mother{  
    public void narrate(Book book){  
        System.out.println("妈妈开始讲故事");  
        System.out.println(book.getContent());  
    }  
}  

public class Client{  
    public static void main(String[] args){  
        Mother mother = new Mother();  
        mother.narrate(new Book());  
    }  
}

假如有一天，需求变成这样：不是给书而是给一份报纸，让这位母亲讲一下报纸上的故事，报纸的代码如下：

1
2
3
4
5
class Newspaper{  
    public String getContent(){  
        return "林书豪38+7领导尼克斯击败湖人……";  
    }  
}

这位母亲却办不到，因为她居然不会读报纸上的故事，这太荒唐了，只是将书换成报纸，居然必须要修改Mother才能读。假如以后需求换成杂志呢？换成网页呢？还要不断地修改Mother，这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了，必须降低他们之间的耦合度才行。
我们引入一个抽象的接口IReader。读物，只要是带字的都属于读物：

1
2
3
interface IReader{  
    public String getContent();  
}

Mother类与接口IReader发生依赖关系，而Book和Newspaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改为：

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
class Newspaper implements IReader {  
    public String getContent(){  
        return "林书豪17+9助尼克斯击败老鹰……";  
    }  
}  
class Book implements IReader{  
    public String getContent(){  
        return "很久很久以前有一个阿拉伯的故事……";  
    }  
}  

class Mother{  
    public void narrate(IReader reader){  
        System.out.println("妈妈开始讲故事");  
        System.out.println(reader.getContent());  
    }  
}  

public class Client {
    public static void main(String[] args) {
        Mother mother = new Mother();
        mother.narrate(new Book());
        mother.narrate(new Newspaper());
    }
}

总结

依赖倒置原则的核心思想是面向接口编程

评论和共享

设计原则：接口隔离原则（ISP）

接口隔离原则

接口隔离原则（Interface Segregation Principle）简称ISP

解释

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

例如：

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
interface I {  
    public void method1();  
    public void method2();  
    public void method3();  
    public void method4();  
    public void method5();  
}  

class A{  
    public void depend1(I i){  
        i.method1();  
    }  
    public void depend2(I i){  
        i.method2();  
    }  
    public void depend3(I i){  
        i.method3();  
    }  
}  

class B implements I{  
    public void method1() {  
        System.out.println("类B实现接口I的方法1");  
    }  
    public void method2() {  
        System.out.println("类B实现接口I的方法2");  
    }  
    public void method3() {  
        System.out.println("类B实现接口I的方法3");  
    }  
    //对于类B来说，method4和method5不是必需的，但是由于接口A中有这两个方法，  
    //所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。  
    public void method4() {}  
    public void method5() {}  
}  

class C{  
    public void depend1(I i){  
        i.method1();  
    }  
    public void depend2(I i){  
        i.method4();  
    }  
    public void depend3(I i){  
        i.method5();  
    }  
}  

class D implements I{  
    public void method1() {  
        System.out.println("类D实现接口I的方法1");  
    }  
    //对于类D来说，method2和method3不是必需的，但是由于接口A中有这两个方法，  
    //所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。  
    public void method2() {}  
    public void method3() {}  

    public void method4() {  
        System.out.println("类D实现接口I的方法4");  
    }  
    public void method5() {  
        System.out.println("类D实现接口I的方法5");  
    }  
}  

public class Client{  
    public static void main(String[] args){  
        A a = new A();  
        a.depend1(new B());  
        a.depend2(new B());  
        a.depend3(new B());  

        C c = new C();  
        c.depend1(new D());  
        c.depend2(new D());  
        c.depend3(new D());  
    }  
}

可以看到，如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口，拆分后的代码如下：

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
interface I1 {  
    public void method1();  
}  

interface I2 {  
    public void method2();  
    public void method3();  
}  

interface I3 {  
    public void method4();  
    public void method5();  
}  

class A{  
    public void depend1(I1 i){  
        i.method1();  
    }  
    public void depend2(I2 i){  
        i.method2();  
    }  
    public void depend3(I2 i){  
        i.method3();  
    }  
}  

class B implements I1, I2{  
    public void method1() {  
        System.out.println("类B实现接口I1的方法1");  
    }  
    public void method2() {  
        System.out.println("类B实现接口I2的方法2");  
    }  
    public void method3() {  
        System.out.println("类B实现接口I2的方法3");  
    }  
}  

class C{  
    public void depend1(I1 i){  
        i.method1();  
    }  
    public void depend2(I3 i){  
        i.method4();  
    }  
    public void depend3(I3 i){  
        i.method5();  
    }  
}  

class D implements I1, I3{  
    public void method1() {  
        System.out.println("类D实现接口I1的方法1");  
    }  
    public void method4() {  
        System.out.println("类D实现接口I3的方法4");  
    }  
    public void method5() {  
        System.out.println("类D实现接口I3的方法5");  
    }  
}

总结

  • 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不争的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
  • 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
  • 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

评论和共享

设计原则：里氏替换原则（SRP）

里氏替换原则

里氏替换原则（Liskov Substitution Principle）简称 SRP

解释

所有引用基类的地方必须能透明地使用其子类的对象。

  • 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
  • 子类中可以增加自己特有的方法。
  • 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
  • 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

总结

子类可以扩展父类的功能，但不能改变父类原有的功能。

评论和共享

设计原则：单一职责原则（SRP）

单一职责原则

单一职责原则（ Single Responsibility Principle ）简称 SRP

解释

规定一个类应该只有一个发生变化的原因

比如这个类：

1
2
3
4
5
6
7
8
public interface IPhone {
    //拨通电话
    public void dial(String phoneNumber);
    //通话
    public void chat(Object o);
    //挂电话
    public void hangup();
}

上面这段代码（IPhone），拥有两个职责，dial 和 hangup 是负责协议管理，chat 负责数据传输。其中只要有一个需要改变就会导致实现类发生改变，所以不符合 单一职责原则 。

应该将这个接口分成两个，让实现类实现这两个接口。

总结

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类的设计是否优良，但是“职责”和“变化原因”确实不可度量的，因项目而异，因环境而异

在实际使用中应该灵活使用

评论和共享

作者的图片

Archie Shi

Nothing to say


Front-End Development Engineer