又重头想了一下
还是以配电脑为例
最开始的时候，需要电脑，你得自己去生产电脑的每一个组件，例如你要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() 方法即属于这种情况。
第二种情况，只是需要一种产品，而不想知道也不需要知道究竟是哪个工厂为生产的，即最终选用哪个具体工厂的决定权在生产者一方，它们根据当前系统的情况来实例化一个具体的工厂返回给使用者，而这个决策过程这对于使用者来说是透明的。
先这样吧