重学设计模式——工厂方法模式

因为这半年忙着换工作，忙着开发公司的项目，没有时间经营自己的博客。
审视了下自己的代码，发现很多时候虽然代码实现了想要的逻辑，但是任然存在着很多隐患，例如不够优雅、耦合高，这些看似不起眼的问题，在后期开发和维护中会给我们添加不少的工作量，所以，重新阅读了何红辉和关爱民前辈的《Android 源码设计模式》一书。

工厂方法模式定义

定义一个用于创建对象的接口，让子类决定实例化哪个类。
该设计模式可运用在任何需要生成复杂对象的场景中，那些new就可以创建的对象就没必要用工厂模式了。

UML类图

UML中主要为四个模块：抽象工厂、具体工厂（实现业务逻辑）、抽象产品、具体产品

写出相对应的java代码：

抽象产品类
public abstract class Product {
    abstract void method();
}

具体产品类A
public class ConcreteProductA extends Product{
    @Override
    void method() {
        // TODO Auto-generated method stub
        System.out.println("产品A");
    }
}

具体产品类B
public class ConcreteProductB extends Product{
    @Override
    void method() {
        // TODO Auto-generated method stub
        System.out.println("产品B");
    }
}

抽象工厂类
public abstract class Factory {
    abstract Product createProduct();
}

生产A类产品的具体工厂
public class ConcreteFactory extends Factory{
    @Override
    Product createProduct() {
        // TODO Auto-generated method stub
        return new ConcreteProductA();
    }
}

客户端
public class Client {

    public static void main(String[] args) {
        Factory factory = new ConcreteFactory();
        Product p = factory.createProduct();
        p.method();
    }
}

输出结果：产品A

我们理一理代码：
Client 中先构建了一个生产A的工厂对象，并且通过其构建了一个A产品的对象，并且执行了A产品的方法。

工厂方法的作用

很多人说 ，直接构建一个类，执行相对应的方法不可以吗？
当然可以，但是忽略了一点，耦合性。
当新的需求出来后，因为要更改一两个方法而牵一发而动全身显然得不偿失。