1.简单工程模式
举例：假如一家动物救助站每天都会有猫狗猪三个动物需要救助，每次救助需要创建实例，那么正常情况，代码就应该这么实现，先判断是什么动物，再创建该动物的实例，而用简单工厂模式，创建一个工厂类，工厂类需要一个什么动物的参数，创建实例的时候先判断是三个动物里面的哪一个，然后再创建，这么做的结果是用户完全不需要知道他是怎么判断或者操作的，只要创建的时候传入狗或者猫即可。
2.工程模式
举例：相对于简单工厂模式，工厂模式需要一个动物类，然后产生对应三个动物的工厂类，每次用户直接创建对应的动物即可。
3.抽象模式
抽象模式在工厂模式的基础上，增加维度，假如不止是三个动物的问题，还要加上动物的受伤程度，严重或者不严重，那么，三个动物工厂还需要负责初始化动物的伤势。
工厂方法模式：每个抽象产品派生多个具体产品类，每个抽象工厂类派生多个具体工厂类，每个具体工厂类负责一个具体产品的实例创建；
抽象工厂模式：每个抽象产品派生多个具体产品类，每个抽象工厂派生多个具体工厂类，每个具体工厂负责多个（一系列）具体产品的实例创建。
下面是一个形象的比喻：
无论是简单工厂模式、工厂模式还是抽象工厂模式，它们本质上都是将不变的部分提取出来，将可变的部分留作接口，以达到最大程度上的复用。拿一个生产水杯（cup）的工厂举例：起初，不用工厂模式，我必须在生产水杯之前知道水杯的材料和形状等水杯的所有特征才能生产，这就是我们的new Cup();这个Cup必须是具体的。厂主发现同一形状的被子，只是材料不同,如一个是玻璃(glass)的，一个是瓷(china)的,但是确要两条生产线，显然有资源浪费的嫌疑。现在厂主生产杯子时先不让生产线知道我要产的是玻璃的还是瓷的，而是让它在不知道具体材料的情况下先做它能做的，等到它把模具做好，只需要向其中填充玻璃原料或者瓷原料就可以造出同一形状的具体杯子了。但是很可惜，java并不能new一个抽象的Cup，所以就有了简单工厂模式。原来是Cup cup=new Cup;现在是SimpleCupFactory.createCup(String cupName),根据cup的名字生产Cup,而createCup返回的是一个实现了 Cup接口或抽象类的具体Cup。简单抽象工厂模式有一个问题，就是当我现在想生产一个同样形状的铁杯时，工厂里并没有定义相应的处理流程，只能更改createCup方法，这就不合理了。我现在只是想生产铁杯，你只要在最后的时候把玻璃原料换成铁的不就行了吗，干嘛还要更改整条生产线呢？于是就有了工厂模式。原来生产线在生产模具的时候还要考虑是为玻璃杯生产的模具还是为铁杯生产的模具，现在它不用管了。CupFactory.createCup()创建Cup.CupFactory是接口或抽象类。实现它的具体子类会创建符合Cup接口的具体Cup。那么现在厂主想要生产水壶(kettle)，用工厂模式就不得不再造一条水壶生产线，能不能在水杯生产线同时生产水壶呢？（水壶也有玻璃，陶瓷的，铁的）这就是抽象工厂模式。