简单工厂模式
工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式。其实这个我们很常见的，就是一种创建模式，创建我们的对象。我们根据当前的不同类型，创建不同类型的对象。
在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。很常见的比如XXX.createInstant(int type);或者没得参数的，那个又是另外的一种工厂模式，对于每一种我们希望不暴露创建类型的类，都有对应的一个工厂的实现。
何时使用：我们明确地计划不同条件下创建不同实例时。
创建一个抽象的父类，子类实现其接口。父类依赖于一个工厂的实现类，根据不同的条件创建不同的子类的实现类。
应用：、您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。这样就我们的客服端隐藏了具体的实现。对于不同的车我们只需要知道名称就好了，就可以创建啦，非常的简单方便。大话设计模式中的操作符，就是这样搞定的，实现不同的操作符的实现类，加法类，乘法类，除法类。让我们的程序松耦合起来~编程是一门艺术啊，慢慢的锻炼才能不断的成长，理论和实践是一样的重要的。
优点：
1、一个调用者想创建一个对象，只要知道其名称就可以了。
2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。
3、屏蔽产品的具体实现，调用者只关心产品的接口。
缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。
下面我们创建不同的图像，通过工厂类进行使用
我们先来看图
这个看起来比较清楚，我们创建我们的图的时候，通过我们的ShapeFactory的方法进行使用。这看起来比较好理解~但是这个工厂模式，并不满足开放-封闭原则（是说我们的软件实体（类，模块，函数等等）应该可以扩展，但是不可以修改实体。对于扩展开发，修改关闭的）。这个原则呢，给我们带了很多的好处，比如可维护，可扩展，可复用，灵活性比较好等等优点啊。这些东西都需要我们去慢慢的体会的。我们设计软件的时候并不要过度的追求抽向，而是当有这个需求的时候才采取这种思路。而不是茫昧的采取够造抽象。发现需要这样的需求在使用修改也不迟。
很明显啊，我们每次增加一个图形类之后，都需要在工厂类中增加一个判断。并不满足这个属性。
来来。慢慢的看我们的怎么去处理这个的。
- 创建我们的图像的抽象，统一的接口
public interface Shape {
void draw();
}
各种实现类啊
Rectangle，Circle……
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Inside Rectangle::draw() method.");
}
}
- 创建一个工厂，根据给定的我们要创建的信息，产生这样的东西
看到，没有！我们每次如果增加不同的图像的话，我们都需要改变这个工厂的实现类，这个是非常不好的。我们使用抽象工工厂的时候就可以解决这个问题，但是带了了问题也是，类太多。看你怎么去考虑这个问题吧，其实好好的想来说，也不是一个比较大的问题吧。
public class ShapeFactory {
//使用 getShape 方法获取形状类型的对象
public Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
}
使用工厂，这个就不用说了涩
public class FactoryPatternDemo {
public static void main(String[] args) {
ShapeFactory shapeFactory = new ShapeFactory();
Shape shape1 = shapeFactory.getShape("CIRCLE");
shape1.draw();
Shape shape2 = shapeFactory.getShape("RECTANGLE");
shape2.draw();
Shape shape3 = shapeFactory.getShape("SQUARE");
shape3.draw();
}
}
这个就完了
在大话设计模式，我们看到计算器设计的工过程。编程的时候我们应该避免过多的去复制，更好的方式是利用代码，重用代码。
单一职责原则，就一个类而言，应该仅仅有一个引起他变化的原因。不要把太对的功能集中在一起，不利于维护，以及我们的模块化。如果一个类的职责过多，就就等Yu我们把这些职责耦合起来了，一个职责变化的时候可能会削弱或者抑制这个类完成其他的职责（是不是经常遇到起！记住不要这丫啊）这种耦合会导致脆弱的设计。当发生变化的时候，设计会遭到意向不到的破坏！ 比如我们的MVC 就是个很好的例子啊，各做各的非常的棒~不要让一个类职责过多，就一个就好了！
