程序员该如何管理后宫：皇后造更多小人（抽象工厂模式）
0x00 前言
书接上文！自从朕教会了皇后如何造小人之后，整个皇宫一片生机盎然，一群小屁孩天天在院子里面蹦跶，热闹是热闹了，但是心思细腻的yyj皇后却不开心了。
为什么？这些小人儿少了几分灵气！你想啊，一个小人儿没有性别、不懂善恶、不知冷暖，总是不容易把它和真正的生命等价。因此皇后强烈要求朕帮她解决这个问题！怎么办？造出更丰富的小人儿来呗。
做过需求的人都知道，接到一个大大的需求后，限于时间和精力等各方面原因，我们一般不会一上来就把一个需求完整地做出来，而是要分好几版来做，先抓核心竞争力！再通过迭代版本逐步完善功能！朕现在就是这个思路，第一期上什么功能？那就先来个性别吧。
现在问题来了：我们只有一个生产使用的阴阳炉，造出来的小人要么都是男性，要不都是女性。这肯定不行啊，那就想办法呗。我们来复制一个阴阳炉，让它们一个造小伙子，一个造萌妹子。
说着简单，做起来也不难，我们把之前的阴阳炉拆成俩，一个男性阴阳炉一个女性阴阳炉。这样就可以开始继续造小人了。
这就是抽象工厂模式的思路。它是工厂模式的升级版本。比较适合于在多个业务品种和业务分类时使用。后面详细讲一下使用方式，以及和抽象工厂模式相关的知识点。
0x01 抽象工厂模式造更多的小人
1. 概述
先上图，来对我们整个抽象工厂模式有一个整体的宏观性把握。
看着这个图是不是感觉有一点点复杂？有一点点蒙圈？其实很简单，没多少内容，如果忘了之前的工厂模式的类图，可以先回顾一下。下面先大概解释一下抽象工厂模式的结构。
和上一版相比，我们做了一些改造：
- ToyFactory接口现在有了两个实现类，一个专门生产男性的阴阳炉，一个专门生产女性的阴阳炉，以后在使用它们的时候，造不同的小人要专门找不同的炉子。
- Toy接口多了一个性别的方法。它的实现变成了几个抽象类AbstractBlackToy、AbstractBlueToy、AbstractRedToy。这三个抽象类类和上一版的小人差不多，然后每一个抽象类的子类再带上了性别的区分。
好吧，朕承认描述的不清楚，还是看图吧。
2. 代码清单 Queen类
还是先上代码看看运行效果吧。
通过代码可以看出来，我们的一个阴阳炉其实相当于一条生产线，想造小伙子就要找MaleToyFactory，想造萌妹子就要找FemaleToyFactory。各司其职。
public class Queen {
public static void main(String[] args) {
//第一条生产线，生产小伙子
ToyFactory maleToyFactory = new MaleToyFactory();
//第二条生产线，生产萌妹子
ToyFactory femaleToyFactory = new FemaleToyFactory();
System.out.println("---生产一个红色的萌妹子！---");
Toy femaleRedToy = femaleToyFactory.createRedToy();
femaleRedToy.getColor();
femaleRedToy.getSex();
femaleRedToy.talk();
System.out.println("---生产一个黑色小伙子！---");
Toy maleBlackToy = maleToyFactory.createBlackToy();
maleBlackToy.getColor();
maleBlackToy.getSex();
maleBlackToy.talk();
}
}
运行结果。
---生产一个红色的萌妹子！---
我是小红人~
红色萌妹子
小红人性格很好，说话也讨人喜欢~~
---生产一个黑色小伙子！---
我是小黑人~
黑色小伙子
小黑人方言太重，平常人听不懂！
3. 代码清单 Toy、AbstractBlackToy、FemaleBlackToy
以这三份代码看一下小人类的继承关系。其它的都类似，就不再贴代码了，如果想跑起来运行，可以从github上把整个代码当下来。
Toy接口：定义了小人的三个主要特征。
public interface Toy {
public void getColor();
public void talk();
public void getSex();
}
AbstractBlackToy抽象类中实现了黑人共有了两个方法：getColor和talk。
public abstract class AbstractBlackToy implements Toy{
public void getColor() {
System.out.println("我是小黑人~");
}
public void talk() {
System.out.println("小黑人方言太重，平常人听不懂！");
}
FemaleBlackToy类继承了AbstractBlackToy，并且实现了Toy接口中的getSex方法。
public class FemaleBlackToy extends AbstractRedToy {
@Override
public void getSex() {
System.out.println("黑色萌妹子");
}
}
4.代码清单 ToyFactory、FemaleToyFactory
ToyFactory接口：这个没什么说的，其实也没做什么改变，在这也看不出来和性别有几毛钱关系。
public interface ToyFactory {
public Toy createBlackToy();
public Toy createBlueToy();
public Toy createRedToy();
}
FemaleToyFactory类：实现了ToyFactory接口，它和MaleToyFactory基本一样，区别就在于他们在返回小人的时候一个返回的是女性，一个返回的男性。
public class FemaleToyFactory implements ToyFactory {
@Override
public Toy createBlackToy() {
return new FemaleBlackToy();
}
@Override
public Toy createBlueToy() {
return new FemaleBlueToy();
}
@Override
public Toy createRedToy() {
return new FemaleRedToy();
}
}
0x02 抽象工厂类
1. 定义
为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类。
当每个抽象产品都有多于一个的具体子类的时候，工厂角色怎么知道实例化哪一个子类呢？比如每个抽象产品 角色都有两个具体产品。抽象工厂模式提供两个具体工厂角色，分别对应于这两个具体产品角色，每一个具体工厂角色只负责某一个产品角色的实例化。
对应到我们的皇后造小人的工程中。有三个抽象产品：红色小人、蓝色小人和黑色小人。每种颜色的小人会有男性和女性两种具体的类型。因此我们就造出来两种阴阳炉工厂，男性阴阳炉只造男性小人，女性阴阳炉只造女性小人。
2. 适用场景
在以下情况可以考虑使用抽象工厂模式：
- 一个系统要独立于它的产品的创建、组合和表示时。
- 一个系统要由多个产品系列中的一个来配置时。
- 需要强调一系列相关的产品对象的设计以便进行联合使用时。
- 提供一个产品类库，而只想显示它们的接口而不是实现时。
3. 优缺点
优点：
- 具体产品从客户代码中被分离出来
- 容易改变产品的系列（比如加一个性别：中性？只要添加一歌新的工厂实现类就可以了）
- 将一个系列的产品族统一到一起创建
缺点：
- 在产品族中扩展新的产品是很困难的，它需要修改抽象工厂的接口
