简单工厂模式
依赖倒置原则（DIP）扶弱抑强 们应该优先依赖于抽象类，而避免依赖于具体类。当这些具体类不稳定时，更应该如此，因此下面的范例
它违反了DIP，SomeApp依赖于接口Shape，而且完全通过Shape接口来使用Shape的实例。它没有使用Square类或者Circle类的任何特定方法。糟糕的是，SomeApp也创建了Square和Circle的实例，因此就不得不依赖于这些具体类。
所以要用Factory模式来修正。
- public interface ShapeFactory {
- public Shape makeCircle();
- public Shape makeSquare();
- }
- public class ShapeFactoryImplementation implements ShapeFactory{
- @Override
- public Shape makeCircle() {
- return new Circle();
- }
- @Override
- public Shape makeSquare() {
- return new Square();
- }
- }
虽然还是要在其它某个地方创建ShapeFactoryImlementation,但是在所有其他的地方却根本不需要创建Square和Circle。而且，当使用一些反射等方法，例如Spring的依赖注入，就可以完全由Spring窗口来创建该实例。
不过还有个问题，针对每个Shape的派生类，ShapeFactory都要有一个对应的方法。这就产生了一个依赖关系环，使得每当Shape要添加一个派生类，就要改变ShapeFactory，为它增加一个方法，比如Shape有一个新派生类Rectangle，那么 ShapeFactory要加一个方法makeRectangle()。
可以牺牲一点类型安全性，来解决这个全副关系环。
- public interface ShapeFactory {
- public Shape make(String shapeName) throws Exception;
- }
- public class ShapeFactoryImplementation implements ShapeFactory{
- @Override
- public Shape make(String shapeName) throws Exception {
- if(shapeName.equals("Circle"))
- return new Circle();
- else if(shapeName.equals("Square"))
- return new Square();
- else
- throw new Exception("Create Shape Fail;");
- }
- }
测试类
- public void testCreateCircle() throws Exception
- {
- Shape s = factory.make("Circle");
- assert(s instanceof Circle);
- }
虽然把Shape的名字拼错的调用者会得到一个运行期错误而不是一个编译错误但如果编写了适当数据的单元测试并且应用测试驱动的开发方法，那么远在这些运行期错误成为问题之前就可以捕获到它们。
在上面的简单工厂模式中，如果使用第一种模式，则需要在客户类中决定是调用makeCircle()还是makeSquare()，这就违背了工厂模式的初衷（即解开客户类和对象创建的耦合，客户类还是需要知道要创建的是circle还是square，这和new对象没什么区别）但如果使用第二种传参数的方法，则完全解开了这种耦合。
这样的话，甚至接口ShapeFactory都不要使用，直接客户类创建工厂对象，再给它传指定参数，它就可以创建所有的对象！！！但是，如果要创建的对象过多，或者创建对象要花费很多代码的话，那么这个工厂将会非常庞大，所以ShapeFactory接口还是必要的，这样就可以创建几个子类还把所有要创建的对象分开，你建这几个对象，我建这几个对象，这样可以使一个大类分割成几个小类，也能使结构更清晰。
工厂方法模式
工厂方法模式和工厂模式结构类似，但它的一个工厂实例只创建一个对象
代码就省略了，大家都懂得，但这里要吐槽一句，其实我一直没觉得工厂方法比简单工厂好在哪里，工厂方法要为了创建不同的对象要创建不同的方法实例，而简单工厂只要创建不同的String对象即可，
- //简单工厂模式 只有一个工厂实例对象
- public void SimpleFactory(){
- Factory f = new FactoryImpl();
- f.create("productA");
- f.create("productB");
- }
- //下面是工厂方法模式 需要多个工厂实例对象
- public void FactoryMethod(){
- Factory fa = new FactoryImplA();
- fa.create();
- Factory fb = new FactoryImplB();
- fb.create();
- }
哪个看起来更好，不言而喻！如果说工厂方法模式相比简单工厂仅有的好处，那就是简单工厂需要传入的名字和对象的名字不断的比较，不仅浪费效率（真的会比创建多个工厂实例对象浪费的多吗？），而且还更丑陋（这才是主要的！）。
抽象工厂
说完工厂，再说说抽象工厂。抽象工厂和工厂完全是两码事。以前我一直以为它是工厂模式的升级版呢。
下面只写SimpleHome和AdvancesHome建造对象方面的代码。
- //SimpleHome
- public Products[] showMyHouse(){
- Products bed = new ProductBed();
- Products door = new ProductDoor();
- return {bed,door};
- }
- //AdvancedHome
- public Products[] showMyHouse(){
- Products bed = new ProductBed();
- Products door = new ProductDoor();
- Products desk= new ProductDesk();
- Products sofa= new ProductSofa();
- return {bed,door,desk,sofa};
- }
这个抽象工厂是用工厂方法模式写的，当然也可以把它改造成简单工厂模式，只要传入个参数"SimpleHome"或者"AdvancedHome"来让工厂实例决定创建哪种对象。
所以我们可以看出，抽象工厂模式和工厂模式虽然都名“工厂”，但它们却关注了不同的两个方面。模式的创建，无非就是低耦合，高聚合。模块与模块之间低耦合，模块内部高聚合。而这两个工厂模式，完全诠释了这一点。
工厂是解决了客户类和对象创建模块之间的耦合，只需要传一个参数，模块就可以创建不同的对象，而客户类对于对象的创建一无所知。而抽象工厂就是种高聚合。它聚合了simlehome和advancedhome对象的创建工程，使得在客户来看创建这两个对象非常简单，如果要simplehome，只需要创建一个SimpleHome工厂，并调用一下方法showMyHouse即可，而如果不用抽象工厂模式，就需要一个床工厂，一个门工厂，来分别创建bed和door对象。而如果Productes的子类更多，那么客户可以需要一堆的工厂。。。。。。。
但抽象工厂也有其自身的缺点，它提高了模块内的聚合性，那么它也降低了灵活性。如上图，你的家可以有一个bed一个door，也可以bed、door、desk、sofa都有，但如果我想要其中的三个，那就得再创建一个工厂实例，需要创建的对象任意组合，都需要相对应的工厂实例，即使是使用简单工厂的传参数方法，也需要一堆的代码加判断。所以抽象工厂更适合使用对象之间关系比较紧密的系统。就象上面所示，你的房子只有两个选择，要么简单的，要么高级的。
但如果我们能使用反射方法，那么就可以用简单工厂模式来传参数，然后再根据参数来创建不同的对象。（所以说简单工厂比工厂方面好太多了啊！）