工厂模式以及应用简单解释

一个jpa引发的血案，项目中应用的jpa比较多，自己看了关于jpa相关的应用，然后打算了解一些源码，但是不太能看懂。想知道为什么在jpa中定义了方法，就能够操作数据库，不定义方法也能操作数据库，资料上说应用的代理设计模式，自己看过一些设计模式，但是并没有太理解。自己又着重看了看代理设计模式，好像还是看不懂，然后跟身边的一个大神，大学的好哥们交流，咨询了一下，代理模式的实现原理。在学技术的时候我走入了一个误区，感觉想深入的学习某项技术就应该了解源码，了解源码是没有问题，但是我们应该从宏观的角度看待问题、了解问题。例如代理模式，我们应用都会用，也都会去了解源码，但是它是怎么实现代理的呢，我了解这个实现过程的时候就是直接去看底层的源码，但是越看好像越迷糊，之所以这样是因为我们没有站在正确的角度看待问题，如果我们知道代理模式是如何实现的，那么了解代理模式的原理就没有那么费劲了，虽然我看问题的角度可能对了，但是学艺不精，仅仅了解一些皮毛呀！我会在以后的博客中介绍代理模式的。
由jpa引起我的一些列要看的东西，反射->代理模式->工厂模式->反射的一系列应用->JPA原理->AOP原理等，希望能全部更新成博客，所以可能最近多更新一些博客。
只有在用到某项的时候，细细琢磨才会发现一些其中的强大，希望大家多多进步，如果有问题希望不吝赐教。

概述

我暂时还没有理解这个工厂模式的所有，只有在特定的场合下这个工厂模式的威力才能展现出来。工厂模式有三种基本形式，当然实现的方式是多样的，
顾名思义，工厂是生产衣服，零件之类的比较多，在这里工厂模式就一个作用，产生对象的。工厂里的产品就是具体的对象，产生对象的地方就是工厂，工厂模式属于创建型设计模式。
下面篇幅我都用的定义：产品工厂->生产具体的产品、产品->具体的产品、产品抽象类->定义某一类产品的和产品工厂是不同的、抽象工厂->产生产品对象的工厂。

简单工厂模式

• 场景介绍：首先定义产品抽象类Car、Boat，那么的产品类别就定了两个，如下的产品就属于这两个类别了，然后定义几个具体的产品。抽象工厂类可以产品这两类产品了（实际上这里并不是的类并不是抽象的，是一个实际的类用于产生具体的产品）
• UML展示类与类之间的关系：用网上的工具画的，还挺好用的，我觉类图有助于理解类与类之间的关系，遇到复杂的类，我觉得画画这个还是挺有用的。

-code：这里我只展示部分，我会把git地址留下。

public class StaticFactory {

    /**
     * CarFactory是一个静态工厂类，初始化只有一个Benz类型的车
     * @return
     */
    public Car getBenz(){
        return new Benz();
    }
    /**
     * 增加同种类型的车
     */
    public Car getBwm(){
        return new Bwm();
    }

    /**
     * 工厂类中增加带参数的不同种类的产品,只需要在工厂类中增加一条即可
     */
    public Boat getBoat(String size){
        return new Yacht(size);
    }

}
    //test类
    StaticFactory staticFactory = new StaticFactory();
    staticFactory.getBenz().type();

• 用法：用一个类用来生成的对象，这个类就是工厂类，它的作用就是产生具体的产品对象，而每一个具体的产品对象，都会在工厂类中初始化，在工厂类中动态的决定生成那个具体产品的对象。
• 增加与删除产品时：在工厂类中增加或者删除对应的产品的对象，增加的产品可以是一类产品，也可不是一类产品。
• 优劣势：
  1）看着类图就会感觉到，其实这个类与类之间的关系太复杂了，类的内聚性太差了，当某个具体的产品类发生改变时，抽象工厂类也需要修改。
  2）对于初始化对象来说确实还是比较方便的。
  3）扩展性也很好。

• 应用介绍：在spring beanFactory中的应用
  

  在spring在xml中配置bean的相关信息，首先spring容器会读取配置文件，将所有的bean初始成对应的对象，并给每个对象起一个名字，然后存入到Map中，map是的键是类的名字，value是bean，这里的bean也就是要创建的具体的产品的对象，这里产品可以有多种，利用map.contain(“key”)方法获取具体的产品的信息,这里产品可以有多种，利用map.contain(“key”)方法获取具体的产品的信息。

工厂模式

• 场景介绍：（每一个模式我都会重新定义场景，有助于理解），定义一个产品抽象类Car、该类产品具体产品、具体的产品工厂类（一个产品对应一个产品工厂类）、抽象工厂类（一类产品对应一个抽象工厂）。

• UML展示类与类之间的关系：
  

  当增加一类产品时，就相当于把这个图重新画一遍。开发的时候也是一样的。
  -code：

//抽象工厂
public abstract  class CarFactoryPattern {

   public abstract Car getCar();


   /**
    * 如果在原有抽象工厂中直接增加一个类型，其他的所有具体的产品产生工厂都需要早呢更加一个类型，
    * 这个类型这个产品也能产生呀，所以就不能增加了,需要新增抽象产品工厂
    * public abstract Boat getBoat();
    * @return
    */

}
//产品工厂
public class BenzFactory extends CarFactoryPattern {

    @Override
    public Car getCar() {
        return new Benz();
    }
}

//test
   CarFactoryPattern carFactoryPattern = new BenzFactory();
   carFactoryPattern.getCar().type();

• 用法：同类产品存在同一个抽象类，每个具体的产品都存在生产该产品的工厂，该工厂用于初始化该产品的对象。抽象工厂类用于选择那种产品的工厂。
• 增加或者删除同类的产品时：首先增加或者删除一个具体的产品，然后增加或者删除产品工厂。
• 增加不同类的产品时：需要新增抽象工厂、产品抽象类、产品工厂、具体产品。ps：新增不同类型的好麻烦呀。
• 如果新的产品中增加参数：也就是初始化对象的时候增加了构造方法中需要入参。那么工厂方法就不太能用了，贼麻烦。
• 优势:
  
  • 产品抽象，生产的产品也抽象，当增加该类产品时，只需增加具体的产品和生产该产品的工程即可
  • 对于增减产品的操作比较方便，扩展性比较好。
  • 抽象工厂类之间的耦合性下降了，降低耦合性还是很有必要的。

抽象工厂模式

• 场景介绍：现在有两种产品抽象类，几个具体的产品，产品工厂，现在产品工厂强大了，能够生产两种产品了，抽象工厂也是一样，能够生产两种产品了。
• UML展示类与类之间的关系：
  
• code：

//产品工厂类
public class BenzNewFactory extends FactoryPattern{

    @Override
    public Car getCar() {
        return new Benz();
    }

    @Override
    public Boat getBoat(String size) {
        return new Yacht(size);
    }
}
//抽象工厂类
public class BenzNewFactory extends FactoryPattern{

    @Override
    public Car getCar() {
        return new Benz();
    }

    @Override
    public Boat getBoat(String size) {
        return new Yacht(size);
    }
}
//test
   FactoryPattern factoryPattern = new BenzNewFactory();
   factoryPattern.getBoat("123").size();
   factoryPattern.getCar().type();

• 抽象工厂模式和工厂方法模式之间的区别：从几个方面
  1）产品抽象类和具体产品（没区别）：需要增加一个产品抽象类和具体的产品。
  2）产品工厂：可以产生多个产品。
  3）抽象工厂：增加一个类别的产品不需要额外的增加抽象工厂，但是增加一个类产品时，其他的不需要的类也可能增加这个产品类别。

其实看起来工厂模式没有什么东西，也容易理解，我在这里举的例子也可能不太恰当，像这种设计模式只有在特定的情况下才能发挥其优势的，虽然可能并没有体会它的深意，也要理解它。

git 地址：
https://github.com/jtracydy/SpringBootTestDemo/tree/master/src/main/java/com/demo/d/factory/own

参考博客:
http://blog.csdn.net/zxt0601/article/details/52798423
http://blog.csdn.net/zxt0601/article/details/52798423
作图工具地址 ：https://www.processon.com/
UML图参考博客：http://blog.csdn.net/jtracydy/article/details/78980315