设计模式-工厂模式与抽象工厂模式

        工厂模式我想大家都应该知道，这里对这个设计模式中的基本模式就不多赘述了，直接上代码，来分析下它的缺点。
     就拿造人这件事来说，我们可以抽象出一个human类来用工厂模式创造出不同国家的人，比如美国人和中国人。
     
      如图为工厂模式的类图，可以发现，如果我想增加一个国家的人是很容易的，只要继承一个，在添加一个create的方法在工厂里就可以了，基本都是添加的动作，没有修改的部分，很符合开放封闭原则。然而，既然是造人工厂，那人总是分男女吧，如果调用者想从工厂中创造出女人怎么办？ 嗯？ 现在你是不是觉得修改有点不像之前想的那么快了，没那么容易了？
     确实，如果想增加女人这个类，可能就想到的就是新增一个女人类，然后让中国人和美国人都去继承或者是女人类封边继承中国人或美国人，然后再工厂中独立的创建关于女人类的方法，但是类型已经不是单纯的human了，这样就不能算是工厂模式了。发现了吗？这就是工厂模式的弊端，工厂模式不能拥抱变化，对于同种类的类型扩展性好。如果只是简单的对于human类进行方法的扩充，增加getsex方法，之后通过在工厂类里增加各个国家男女的方法，那对于客户端的修改必定是个灾难。
   对于这个缺点，抽象工厂模式就大有用处了。
  Provide an interface for creating families of related or dependent objects without specifying their concrete classes。 为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类
    抽象工厂类图：
  
     抽象工厂模式比工厂模式的优势在于：工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则是针对的多个产品等级结构。
     抽象工厂相比于工厂模式的好处就在于同类产品的不同分类上的扩展，就拿人来说，工厂模式对于创造人这个功能是够用的，但是如果要涉及到分别创造人类中的女人和男人两种产品就很麻烦了，抽象工厂很好的弥补了这个缺点。 
     
     总结：
      抽象工厂模式的使用场景，可以用在创建同种产品的不同规格下，也就是横向扩展的应用中，比如，我要实现一个线程类，但是这个线程类要满足吧linux和win平台，这样用抽象工厂模式，在日后对于ios和android的扩展就相当的容易了。