关于工厂模式(三)

又重头想了一下

还是以配电脑为例
最开始的时候，需要电脑，你得自己去生产电脑的每一个组件，例如你要cpu 就得自己生产cpu 要主板就得自己生产主板。
于是出现

简单工厂模式
在简单工厂模式中，定义一个返回接口，然后所有的组件实例都从这个工厂中产生
例:

     工厂---------生产硬件 
     硬件----------
            cpu------硬件的子类
            主板------硬件的子类

    当我需要某种组件的时候，直接告诉工厂，我需要的硬件名字，然后工厂就会生产一个我需要的硬件给我，这里，我不用去知道工厂中是怎么生产的，他可以自己生产，也可以找别的工厂代工，与我无关，我只需要找这个工厂要硬件就行了。

   工厂类
   public class Factory
  {
      public IHardware Produce(int type)
     {
          swicth(type)
         {
                case 0:
                     return new Cpu();
                break;
                case 1:
                    return new Motherboard();
                break;
                Default:
                    return null;
                break;                
          }
      }
   }

  硬件接口
  public Interface IHardware 
 {
 }

  具体类CPU

 public Cpu implements IHardware 
{
}

 具体类主板
public Motherboard implements IHardware 
{
}
使用时，只需要一个工厂，然后找那个工厂生产实例就行了
Factory factory=new Factory();
IHardware cpu=factory.Produce(0);
IHardware motherboard=factory.Produce(1);

缺点

　　由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。 

　　当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利； 

　　这些缺点在工厂方法模式中得到了一定的克服。 

　　使用场景 

　　工厂类负责创建的对象比较少； 

　　客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心； 

　　由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。

 

工厂方法模式应该和抽象工厂模式说的是同一个东东

那就还是用配电脑来重新理解一下

例如，原本只有一种cpu，一种主板，后来出现了很多种cpu和主板，这时使用这个工厂就会很麻烦，因为每次有新的类型出来，我都得去修改这个工厂

于是就出现了抽象工厂模式

这个理解上还有点问题，在代码中再考虑吧只需要知道它在哪里用到

工厂方法模式的应用

　　工厂方法经常用在以下两种情况中: 

　　第一种情况是对于某个产品，调用者清楚地知道应该使用哪个具体工厂服务，实例化该具体工厂，生产出具体的产品来。Java Collection中的iterator() 方法即属于这种情况。 

　　第二种情况，只是需要一种产品，而不想知道也不需要知道究竟是哪个工厂为生产的，即最终选用哪个具体工厂的决定权在生产者一方，它们根据当前系统的情况来实例化一个具体的工厂返回给使用者，而这个决策过程这对于使用者来说是透明的。

先这样吧