一、简单工厂
用一个单独的类来做这个创造实例的过程
如下图:
![简单工厂](/2021/04/09/ThreeFactory/20210123180215617.png)
Factory类作为工厂类,外部程序只需要知道Factory类就行创建Cat、Dog、Pig类,对底层进行了封装。那么,简单工厂怎么确定该初始化那个子类呢?简单工厂需要对创建方法传入一个标识值用以标识创建哪个对象。
问题:
若使用简单工厂,而该工厂需要创建的类的种类很多,那么会出现什么情况?
答:在该工厂类中会出现大量的判断,一股“坏代码的味道”。
二、工厂方法
定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到子类。
如下图:
![工厂方法](/2021/04/09/ThreeFactory/20210123191451412.png)
由Factory父类派生出三个工厂子类,这三个工厂子类分别对Cat、Dog、Pig类进行创建。简单工厂在面对许多需创建的种类使遇到的瓶颈在工厂方法设计模式得到了很好的解决。
三、抽象工厂
提供一个创建一系列相关或相互依赖的对象接口,而无需指定它们的具体的类。
如下图:
![抽象工厂](/2021/04/09/ThreeFactory/202101232225412.png)
抽象工厂对工厂方法进一步的抽象,参考此场景:一天,你需要写一个猫接口,猫有俩个子类,家养猫和野生猫。这时你用工厂方法是没错的,因此你创建了一个猫工厂,猫工厂派生出俩个工厂:一个家养工厂,一个野生工厂。如果这时候又增加了一个需求,需要你在写一个狗接口,狗有俩个子类,家养狗和野生狗。这时候你该怎么做?或许你可以在写个狗的工厂,但是大可不必,像上图,一种高内聚的写法。写出野生工厂和家养工厂,这就是抽象工厂。
四、总结
对于一般情况,简单工厂可以很好的解决问题,将需要保护的类很好的封装起来。但是,当类多起来时,简单工厂的创建类的判断显得十分的冗余,工厂方法也就登场了,它对工厂进行了抽象,由子工厂确定创建何种类。抽象工厂是对工厂方法的进一步抽象,它看起来非常的庞大,这也是它的确定,所以,只有工厂方法不合适时才考虑是否使用抽象工厂。
“没有最好的设计模式,只有最合适的!”