《图解设计模式》笔记（二）交给子类

三、Template Method模式：将具体处理交给子类

示例程序类图

在这里插入图片描述

public static void main(String[] args) {
    // 生成一个持有'H'的CharDisplay类的实例
    AbstractDisplay d1 = new CharDisplay('H');
    // 生成一个持有"Hello, world."的StringDisplay类的实例
    AbstractDisplay d2 = new StringDisplay("Hello, world.");
    // 生成一个持有"你好，世界。"的StringDisplay类的实例
    AbstractDisplay d3 = new StringDisplay("你好，世界。");
    // 由于d1、d2和d3都是AbstractDisplay类的子类，可以调用继承的display方法，实际的程序行为取决于CharDisplay类和StringDisplay类的具体实现
    d1.display();
    d2.display();
    d3.display();
}

角色

在这里插入图片描述

AbstractClass（抽象类）

不仅负责实现模板方法，还负责声明在模板方法中所使用到的抽象方法。

这些抽象方法由子类ConcreteClass角色负责实现。

在示例程序中，由AbstractDisplay类扮演此角色。
ConcreteClass（具体类）

该角色负责具体实现AbstractClass角色中定义的抽象方法。这里实现的方法将会在AbstractClass角色的模板方法中被调用。

在示例程序中，由CharDisplay类和stringDisplay类扮演此角色。

扩展思路的要点

可以使逻辑处理通用化

本模式的好处：在父类的模板方法中编写了算法，无需在每个子类中再编写算法。若模板方法中发现Bug，只需修改模板方法即可。

假设没使用Template Method模式，而是复制粘贴编写了多个ConcreteClass角色，会出现ConcreteClassl、ConcreteClass2、ConcreteClass3等很多相似的类。其中一个有bug，其他类似的都得跟着再改一遍。

父类与子类之间的协作

本模式中，父类和子类是紧密联系、共同工作的。

因此，在子类中实现父类中声明的抽象方法时，必须要理解这些抽象方法被调用的时机。若看不到父类的源代码，很难编写出子类。

父类与子类的一致性

在示例程序中，不论是CharDisplay的实例还是stringDisplay的实例，都是先保存在AbstractDisplay类型的变量中，然后再来调用display方法的。

使用父类类型的变量保存子类实例的优点是：即使没有用instanceof等指定子类的种类，程序也能正常工作。

无论在父类类型的变量中保存哪个子类的实例，程序都可以正常工作，这种原则称为里氏替换原则（The Liskov Substitution Principle，LSP)。当然，LSP并非仅限于Template Method模式，它是通用的继承原则。

四、Factory Method模式：将实例的生成交给子类

示例程序类图

在这里插入图片描述

Factory.java中的create方法如下，另外两个方法都是abstract

public final Product create(String owner) {
    Product p = createProduct(owner);
    registerProduct(p);
    return p;
}

测试

public static void main(String[] args) {
    Factory factory = new IDCardFactory();
    Product card1 = factory.create("小明");
    Product card2 = factory.create("小红");
    Product card3 = factory.create("小刚");
    card1.use();
    card2.use();
    card3.use();
}

角色

父类（框架）这一方的Creator角色和Product角色的关系，与子类（具体加工）这一方的ConcreteCreator角色和ConcreteProduct角色的关系，是平行的。

在这里插入图片描述

Product（产品）

属于框架这一方，是一个抽象类。

它定义了在Factory Method模式中生成的那些实例所持有的接口（API），但具体的处理则由子类ConcreteProduct角色决定。

在示例程序中，由Product类扮演此角色。
Creator（创建者）

属于框架这一方，是负责生成Product角色的抽象类，但具体的处理则由子类ConcreteCreator角色决定。

在示例程序中，由Factory类扮演此角色。

Creator角色对于实际负责生成实例的ConcreteCreator角色一无所知，它只知道：调用Product角色和生成实例的方法（图中的factoryMethod方法），就可以生成Product的实例。

在示例程序中，createProduct方法是用于生成实例的方法。生成实例不是用new关键字而是调用生成实例的专用方法，这样可以防止父类与其他具体类耦合。
ConcreteProduct（具体的产品）

属于具体加工这一方，它决定了具体的产品。

在示例程序中，由IDCard类扮演此角色。
ConcreteCreator（具体的创建者）

属于具体加工这一方，它负责生成具体的产品。

在示例程序中，由IDCardFactory类扮演此角色。

扩展思路的要点

框架与具体加工

这里，让我们用相同的框架创建出其他的“产品”和“工厂”。

例如，我们这次要创建表示电视机的类Televison和表示电视机工厂的类TelevisonFactory。

这时，我们只需要引入（import）framework包就可以编写televison包。

请注意，根本没有必要修改framework包中的任何内容，就可以创建出其他的“产品”和“工厂”。

请回忆一下，在framework包中我们并没有引入idcard包。在Product类和Factory类中，并没有出现IDCard和IDCardFactory等具体类的名字。

因此，使用已有的框架生成全新的类时，也完全不需要对framework进行修改，即不需要“将televison包引入到框架中”。

关于这一点，我们称作是“framework包不依赖于idcard包”。

生成实例——方法的三种实现方式

在示例程序中，Factory类的createProduct方法是抽象方法，也就是说需要在子类中实现该方法。

createProduct方法的实现方式一般有以下3种。

1.指定其为抽象方法

一旦将createProduct指定为抽象方法后，子类就必须实现该方法，否则编译错误。这也是示例程序所采用的方式。

public abstract Product createProduct(String name);

2.为其实现默认处理

实现默认处理后，如果子类没有实现该方法，将进行默认处理。

不过，这时是使用new关键字创建出实例的，因此不能将Product类定义为抽象类。

public Product createProduct(String name) {
    return new Product(name);
}

3.在其中抛出异常

createProduct方法的默认处理为抛出异常，这样如果未在子类中实现该方法，程序就会在运行时出错（报错，告知开发人员没有实现createProduct方法）。

使用模式与开发人员之间的沟通

建议在程序注释中和开发文档中记录所使用的设计模式的名称和意图，以免被其他开发同事瞎改。