1 工厂模式
1.1 没有工厂
小佑需要一个篮球，就new一个篮球来用。
小佑需要知道如何制造篮球，小佑和篮球紧紧的耦合在一起。
1.2 简单工厂模式
为了降低耦合，出现了工厂类，制造篮球的细节都在工厂类里面。
篮球类是一个抽象类，不同型号的球实现这个篮球类表示自己是一个篮球。
小佑觉得自己做篮球太累了，建了一个篮球工厂。
小佑直接调用工厂的创建方法，传入需要的篮球型号就行。（舒服了）
篮球 一个室内篮球 = 工厂.创建（室内篮球）
篮球 一个室外篮球 = 工厂.创建（室外篮球）
然而有一天，举办一个投篮活动，需要一个花色球。
简单！从产品类的角度 写一个新的花色球类，实现篮球接口就行。
但是！在工厂类中，需要增加相应的业务逻辑：如果需要一个花色球，创建一个花色球。
明显不符合开闭原则。
如果今天加红色球，明天加蓝色球，工厂类表示压力很大。
1.3 工厂方法模式
显然一个工厂完成所有的篮球生产有点困难，需要不断的扩充业务。
聪明的小佑想：那不如每种篮球都建一个工厂吧。（听起来有点蠢，但是对未来业务拓展提供了方便）
简单修改如下：
工厂类作为一个抽象类规定必须实现的接口。（比如create方法）
工厂子类 完成每种篮球的生产（具有部分决定权，但是又受制于工厂抽象类）。
需要红色球就找红色球工厂生产红色球
需要蓝色球就找蓝色球工厂生产蓝色球
如果后天业务变更，需要一个粉色篮球，就新增一个粉色篮球类，对应增加一个粉色篮球工厂。
小佑就可以 通过粉色球工厂 生产一个粉色球了。
不需要修改已有的代码。（再次舒服）
工厂方法模式将实例化推迟到子类，在父类做规定和限制（需要时可以声明一些final禁止子类改变）。
1.4 抽象工厂模式
突然又有一天，小佑发现蓝色球和红色球的手感竟然相差巨大，红色球似乎用了劣质球皮。
一定是红色球类在new红色球的时候使用了劣质材料。这怎么可以！得想想办法。
我建立一个抽象的原料工厂，提供球皮、球芯、颜料。
让红色球的原料工厂实现这个原料工厂，同样提供球皮、球芯、颜料，但是颜料是红色。
让绿色球的原料工厂实现原料工厂，同样提供如上原料，颜料是绿色。
红色球类组合一个红色球原料工厂，使用红色球原料工厂的原料制作。
绿色求类组合一个绿色球原料工厂，使用绿色球原料工厂的原料制作。
但是除了颜料之外都受抽象原料工厂管制。（保证了球的颜色不同手感一致，再次舒服）
如果这里不适用抽象工厂，使用工厂模式呢？那就要提供球皮工厂，球芯工厂，红色颜料工厂…
而在红色球类中，要组合很多工厂，一个一个的要材料。
如果有一天红色球类需要优化，需要略微调整颜色，优化球芯、球皮手感。就需要在内部修改代码。违反开闭原则。
使用抽象工厂模式。只需要更换红色球类组合进来的工厂即可，可是实现一个全新的红色球原料工厂替换原来的原料工厂，不影响其他代码。
抽象工厂模式声明一个接口，用于创建相关或依赖的一个产品家族（一个产品的集合）。从实际工厂中解耦，红色球类只需要使用工厂即可，不需要实例化任何球皮、球芯、颜料对象。并且可以通过替换工厂实现不同的行为。
但是如果要拓展产品集合的内容，仍然需要修改代码。（所以选择设计模式，找到不变和变 至关重要）
归根结底，抽象工厂模式的核心词是：“产品家族”（产品集合）。
1.5 总结
不论是工厂方法还是抽象工厂，都能将对象的创建封装起来和应用程序解耦，降低了对特定实现的依赖。
设计原则：依赖抽象而不依赖具体类。