工厂方法模式”与抽象工厂模式

相较于“简单工厂模式”，“工厂方法模式”是将实例化对象的操作延迟到了子类去实现，而前者是另起一个类去实现。

三、工厂方法

一个小demo理解工厂方法：

①产品(某一类型)：
定义产品的接口

public interface Product {}

具有相同类型的一些相应产品

//产品1
public class ConcreteProduct1 implements Product {}
//产品2
public class ConcreteProduct2 implements Product {}

②工厂
总工厂（该工厂主要为上面类型的产品服务）：

public abstract class Creator {
    abstract Product factoryMethod();
}

分工厂（客户主要使用的工厂,当前主要负责生产产品1）

  public class ConcreteCreator extends Creator {
    Product factoryMethod() {
        return new ConcreteProduct1();
    }
}

③客户（或者说是其他地方需要上面类型的产品，就需要从分工厂获取）

public class Client {
    public static void main(String[] args) {
        //我想要产品1,从产品1的分工厂去拿产品
        Creator product1 = new ConcreteCreator();
        System.out.println(product1.factoryMethod());
    }
}

番外：
个人理解：
“简单工厂模式” 下的对客户端实例化对象的选择交给了简单工厂，在客户端无需去进行逻辑判断，但是这种模式下，简单工厂是通过修改逻辑判断代码来实现的，在这种情况下，业务越来越多，代码改的越来越频繁，很容易出错，当然其简单工厂又是可见的，所以不符合“开闭原则”。工厂方法相当于简单工厂的一个升级版，工厂方法是符合开闭原则的。

而在“工厂方法模式”中，当新增加一个产品，以前的产品依然可以正常的使用，除非不要这个产品，那么就需要取消掉相应产品和相应的实现工厂方法的类，以及客户端对这个产品的使用的那些类。当然对于新增产品的话，只需要新增实现工厂方法的类就可以。客户端调用这个实现工厂方法的类，即可进行相应的业务。减少耦合。

当然这样一来，也有诟病，那就是如果业务不断升级，不断有产品新增，那么实现工厂方法的类也就越来越多。

四、抽象工厂模式

对于抽象工厂模式，其实就是多个实现工厂方法的类合在一起的模式，从上面的例子中，也就是说：

扫描二维码关注公众号，回复： 5227350 查看本文章

几个不同分工厂合在一起：

public class ConcreteCreator extends Creator {
    Product factoryMethod1() {
        return new ConcreteProduct1();
    }
    Product factoryMethod2(){
        return new ConcreteProduct2();
    }
}

当然他们的总工厂要“允许它们合在一起”：

public abstract class Creator {
    abstract Product factoryMethod1();
    abstract Product factoryMethod2();
}

这只是一个简单的抽象工厂，真正的抽象工厂设计模式，可以构成一个家族树。这也类似于大企业。