java工厂模式
设计模式在设计的时候需要遵循一些原则：（类设计依赖关系）
1、 开闭原则：扩展开放，修改关闭 ：需求改了 ，尽量不要改源代码，可以扩展功能
2、 里式变换原则：必须保证父类的东西，子类依然成立，子类继承父类，可以继承功能，尽量不要重写
3、 依赖倒置原则：尽量保证高层不要依赖底层， 抽象不要依赖具体
4、 单一职责原则：一个类做一个事情，不同的功能和职责拆开
5、 接口隔离原则：将庞大的接口拆分开，一种单一职责的体现，单一职责注重细节，接口隔离更注重约束
7、 迪米特原则：最少知识原则。尽量与自己交流，两个对象之间没有必然联系，不要交流通过第三方完成（解耦）
8、 合成复用原则：尽量使用组合关系然后在考虑继承关系
工厂的职能是什么？创造而且是创造很多东西；想创造什么、怎么创造什么、由谁决定——工厂本身，带着这两句话我们思考工厂模式。
本人家中有很多做饭的电器，有的电器用来煲汤，有的电器用来煎东西。这些电器有最基本的职能就是做饭。但是这么多电器，做饭应该怎么做呢，温度应该加温到多少呢，这些应该都需要一些国际标准来约定。这样一来，这个电器的市场才是可控的，来避免有的拿来吹风的电器拿来做烤肉。
这个在java中就是类与接口的关系，实现了接口的类，必须要实现接口规定的职能。所以接口一定程度上起到了封装的规范的作用，你想要我功能，请你先遵守我的规矩。
如上代码缺点：
但是这个时候用户的目的是什么他只是想要煲汤，但是他今天一是看一遍电器的规则使用说明，二是根据说明自己造了一个电饭煲。
这煲汤的代价是不是太大了些，这我觉得并不符合符合单一职责原则，我作为一个干活的类，我觉得我就忙着干活就行了，而不是我干活的时候还需要为了干活而去创造个工具，是不是有种可能我可用找的仓库拿个工具呢。
调用对象方法时候时候不但能看的到接口，同时还暴露了具体的具体的实现类（我自己还得new对象）按照设计原则违背了一个封装隔离思想(你要我的东西可以，但是我的东西怎么创建的，给你的具体是什么你不应该知道)。
为了解决以上的问题，需要一个中间类把用户和真实需要的对象隔离开来，帮你做封装对象的创建和传递对象的功能。这个功能怎么实现，用户并不知道，他只需要找中间类要就行了。
这个中间类夺走了用户为了达到目的创建一个对象，这个对象的创建全由中间人管理，学过spring的同学对这句话挺熟悉这就是很有IOC对象托管的思想。
用户对这个要使用的对象，虽然是个hasa关系，但在我的眼里，用户没有实际拥有它，有使用权却没有所有权，这样用户可以专心干自己的事情，想要什么不用再自己创建赋值，而是直接找一个中间类要。
这个中间类叫做工厂。
中间设立一个类—目的是为了帮用户创建具体类的对象。
这样的工厂类生产对象有三个好处——
1.统一管理，方便
2.用户和真正实现类解开
3.隐藏真实类的实现只留下了一些元素（规则工厂）
但是问题是——
1、 用户找工厂创建还是需要告诉工厂参数，来说自己需要什么参数，首先都能有些什么参数用户需要再去阅读这个工厂类的API 增加了使用成本，并且参数多了，用户还是能知道不少东西，而优秀的封装某种层面上讲就是把用户当傻子。
2、 工厂类内部应该需要有很多优化，控制的对象是单例还是对象池，是否延迟加载等待
RECOMMEND
推荐阅读
