设计模式六大原则及常用模式详解

设计模式六大原则

1、单一职责原则（Single Responsibility Principle）

定义 : 应该有且只有一个原因引起类的变化
注意 : 这里的类不光指类,也适用于方法和接口,比如我们常说的一个方法实现一个功能

2、里氏代换原则（Liskov Substitution Principle）

定义 : 只要父类出现的地方子类就一定可以出现,而且替换为子类也不会出现任何异常或错误,使用者不需要知道是父类还是子类.但是返回来就不行了,有子类出现的地方,不一定能使用父类

使用规范 :子类必须完全实现父类的方法,如果子类无法完全实现父类的方法,则建议断开父子继承关系,采用依赖 聚集 | 组合 等关系来代替。
子类可以有自己的个性，覆盖或实现父类的方法时,输入参数可以被放大,比如父类中有一个方法的输入参数是 HashMap,子类的参数可以是 Map 类型,这样父类就可以被子类替换,如果反过来,则违背了里氏替换原则,所以子类中方法的前置条件必须与父类的被覆写的方法的前置条件相同或者更宽松
覆写或实现父类的方法时,输出结果可以被缩小,也就是说如果父类方法返回的类型 T,子类的相同方法
(重载或覆写)的返回值类型 S,S 和 T 要么同类型,要么 S 是 T 的子类;跟上面的道理一样
注意 : 采用里氏替换原则时,尽量避免子类的"个性",一旦子类有了"个性",子类和父类的关系就会变得不好调和

3、依赖倒置原则（Dependence Inversion Principle）

定义 : 依赖倒置原则包含三个含义

• 高层模块不应该依赖低层模块,两者都应该依赖其抽象
• 抽象不应该依赖细节
• 细节应该依赖抽象

高层模块和低层模块比较好理解,每一个逻辑都是由原子逻辑组成的,不可分割的原子逻辑是低层模块,原子逻辑再组装就是高层模块;
抽象指的是接口或者抽象类,两者都不能直接实例化;
细节就是实现类,实现接口或继承抽象类而产生的类就是细节,其特点是可以被实例化;

依赖倒置原则在 Java 中的实现是表现是:
模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生
的;
接口或抽象类不依赖于实现类实现类依赖接口或抽象类。这也是面向接口编程的精髓之一

遵循的规则 :

• 每个类尽量都有接口或抽象类,或者两者都有
• 变量的表面类型尽量是接口或者抽象类
• 任何类都不应该从具体类派生
• 尽量不要覆写基类的方法,如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写

结合里氏替换原则使用
接口负责定义 public 属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现,实
现类准确的实现业务逻辑

4、接口隔离原则（Interface Segregation Principle）

我们先来看接口的定义 :
实例接口 : 在 Java 中声明一个类,然后用 new 关键字产生一个实例,它是对一类事物的描述,可以看成是一个接口
类接口 : 使用 interface 定义的接口

隔离的的理解 :
客户端不应该依赖它不需要的接口
类之间的依赖关系应该建立在最小的接口上
概括 : 建立单一接口,不要建立臃肿庞大的接口,也就是接口尽量细化,接口中的方法尽量少，这个是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

接口隔离原则的约束条件 :接口要高内聚,意思就是提高接口,类,模块的处理能力,减少对外的交互,再具体一点就是在接口中尽量减少对外的 public 方法,通过业务逻辑压缩接口中的 public 方法，定制服务,就是单独为一个个体提供优良的服务,比如我们写用户模块的时候,需要给用户提供查询信息,
修改密码,注册用户等信息,当管理员执行相同操作的时候,一般人会复用这些方法,
然后在这个的基础上再增加管理员自己的方法,这种设计方法肯定是有问题的,这样设计,当你修改了普通用户调用的接口实现时,管理员的实现也会发生不可预测的改变,我们应该为管理员单独写一个接口
接口设计是有限度的,接口的设计粒度越小,系统越灵活,这是肯定的,但灵活的同时带来的问题是 结构
复杂化,开发难度增加, 可维护性降低
一个接口只服务于一个子模块或业务逻辑
已经被污染了的接口,尽量去修改 ,若修改的风险较大,则采用适配器模式进行转化处理
了解环境,拒绝盲从,不要一味的去套设计模式,有的时候不用比用了更好,也不要去照搬别人的设计方
法,他的方法到你这不一定效果就好,毕竟业务逻辑不一样

5、迪米特法则（Demeter Principle）

定义 : 迪米特法则也叫最少知识原则,含义是 一个对象应该对其他对象有最少的了解,这个应该很好理解,就是降低各模块之间的耦合

6、开闭原则（Open Close Principle）

定义 : 一个软件实体如类,模块和函数应该对扩展开放,对修改关闭,开闭原则也是其他五个原则的基石

总结

• 单一职责原则告诉我们实现类要职责单一；
• 里氏替换原则告诉我们不要破坏继承关系；
• 依赖倒置原则告诉我们要面向接口编程；
• 接口隔离原则告诉我们在设计接口的时候要精简单一；
• 迪米特法则告诉我们要降低耦合
• 开闭原则告诉我们要对扩展开发，对修改关闭；

对这六个原则的遵守并不是是和否的问题，而是多和少的问题，也就是说，我们一般不会说有没有遵守，而是说遵守程度达到多少，任何事过犹不及，设计模式六个设计原则也是一样，制定这六个原则并不是一味的要求我们去遵守他们，而是根据实际情况灵活运用，

单例模式

单例模式可以分为懒汉式和饿汉式：

• 懒汉式单例模式：在类加载时不初始化。
• 饿汉式单例模式：在类加载时就完成了初始化，所以类加载比较慢，但获取对象的速度快。

第一种（懒汉，线程不安全）:

public class SingletonDemo1 {
	private static SingletonDemo1 instance;
	private SingletonDemo1(){}
	public static SingletonDemo1 getInstance(){
		if (instance == null) {
		instance = new SingletonDemo1();
		}
	return instance;
	}
}

这种写法lazy loading很明显，但是致命的是在多线程不能正常工作。

第二种（懒汉，线程安全）：

public class SingletonDemo2 {
	private static SingletonDemo2 instance;
	private SingletonDemo3(){}
	//这种写法在getInstance()方法中加入了synchronized锁。能够在多线程中很好的工
	作，而且看起来它也具备很好的lazy loading，但是效率很低（因为锁），并且大多数
	情况下不需要同步。
	public static synchronized SingletonDemo2 getInstance(){
		if (instance == null) {
		instance = new SingletonDemo2();
		}
	return instance;
	}
	//这样处理就没有问题了吗？同样的原理，线程A和线程B，线程A读取instance值为null，此时cpu被线程B抢去 	
	了，线程B再来判断instance值为null，于是，它开始执行同步代码块中的代码，对instance进行实例化。此时，线
	程A获得cpu，由于线程A之前已经判断instance值为null，于是开始执行它后面的同步代码块代码。它也会去对
	instance进行实例化。这样就导致了还是会创建两个不一样的实例。
	private static SingletonDemo2 getInstance(){
		if (instance == null) {
			synchronized (SingletonDemo2 .class){
				instance = new SingletonDemo2();
			}
		}
		return instance;
	}
	//在同步代码块中instance实例化之前进行判断，如果instance为null，才对其进行实例化。这样，就能保证
	instance只会实例化一次了。也就是所谓的双重检查加锁机制。
	private static SingletonDemo2 getInstance(){
		if (instance == null) {
			synchronized (SingletonDemo2 .class){
				if (instance == null) {
				instance = new SingletonDemo2();
				}
			}
		}
		return instance;
	}
}

看起来第三种已经是线程安全的了，但是真的是吗？其实双重检查加锁并不代码百分百一定没有线程安全问题了。因为，这里会涉及到一个指令重排序问题。

instance = new Singleton2()其实可以分为下面的步骤：

1.申请一块内存空间；

2.在这块空间里实例化对象；

3.instance的引用指向这块空间地址；

在JVM的即时编译器中存在指令重排序的优化。
也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。

再稍微解释一下，就是说，由于有一个『instance已经不为null但是仍没有完成初始化』的中间状态，而这个时候，如果有其他线程刚好运行到第一层if (instance ==null)这里，这里读取到的instance已经不为null了，所以就直接把这个中间状态的instance拿去用了，就会产生问题。这里的关键在于线程T1对instance的写操作没有完成，线程T2就执行了读操作。
加上volatile关键字，因为volatile可以禁止指令重排序。

public class SingletonDemo2 {
    	private static volatile SingletonDemo2 instance；
    	private SingletonDemo3(){}
		private static SingletonDemo2 getInstance(){
			if (instance == null) {
				synchronized (SingletonDemo2 .class){
					if (instance == null) {
    				instance = new SingletonDemo2();
    				}
    			}
    		}
    		return instance;
		}
    }

volatile关键字的一个作用是禁止指令重排，把instance声明为volatile之后，对它的写操作就会有一个内存屏障，这样，在它的赋值完成之前，就不用会调用读操作。

注意：volatile阻止的不是singleton = new Singleton()这句话内部[1-2-3]的指令重排，而是保证了在一个写操作（[1-2-3]）完成之前，不会调用读操作（if (instance == null)）。
第三种（饿汉）：

public class SingletonDemo3 {
	private static SingletonDemo3 instance = new SingletonDemo3();
	private SingletonDemo3(){}
	public static SingletonDemo3 getInstance(){
	return instance;
	}
}

这种方式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，这时候初始化instance显然没有达到lazy loading的效果。

第四种（饿汉，变种）：

public class SingletonDemo4 {
private static SingletonDemo4 instance = null;
static{
instance = new SingletonDemo4();
}
private SingletonDemo4(){}
public static SingletonDemo4 getInstance(){
return instance;
}
}

工厂模式

简单工厂模式(Simple Factory Pattern)

从简单的工厂模式开始说起的话，我们要知道工厂模式的目的是什么？工厂模式的目的在于程序的可扩展性。而对于简单工厂模式来说，它是为了让程序有一个更好地封装，降低程序模块之间的耦合程度。
对于简单的工厂模式，其实也可以将其理解成为一个创建对象的工具类。工具类的形式，可以仿造如下代码编写：

public class SimpleFactory {

    public Object create(Class clazz) {
	    if (clazz.getName().equals(Plane.class.getName())) {
	    	return createPlane();
	    } else if (clazz.getName().equals(Broom.class.getName())) {
	    	 return createBroom();
	    }
    
     return null;
    }
    
    private Broom createBroom() {
    	 return new Broom();
    }
    
    private Plane createPlane() {
   	 	return new Plane();
    }
 }

测试代码如下：

public class FactoryTest {

	public static void main(String[] args) {
		 // 简单工厂模式测试
		 SimpleFactory simpleFactory = new SimpleFactory();
		Broom broom = (Broom) simpleFactory.create(Broom.class);
		broom.run();
	}
}

正如之前所说的，简单的工厂模式，就是去创建一个创建对象的工具类。在这个工具
类里面，我们就可以进行一些其他操作，比如对象的初始化。这样就避免了把对象初
始化的大量代码(如果有大量代码的话)放在构造函数里了。
优点：简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。明确区分了各自的职责和权力，有利于整个软件体系结构的优化。
缺点：很明显工厂类集中了所有实例的创建逻辑，容易违反GRASPR的高内聚的责任分配原则

工厂方法模式(Factory Method Pattern)

可以一定程度上解耦，消费者和产品实现类隔离开，只依赖产品接口(抽象产品)，产品实现类如何改动与消费者完全无关。

可以一定程度增加扩展性，若增加一个产品实现，只需要实现产品接口，修改工厂创建产品的方法，消费者可以无感知（若消费者不关心具体产品是什么的情况）。
可以一定程度增加代码的封装性、可读性。清楚的代码结构，对于消费者来说很少的代码量就可以完成很多工作。

另外，抽象工厂才是实际意义的工厂模式，工厂方法只是抽象工厂的一个比较常见的情况。
抽象工厂：
我们的抽象工厂可以是类似这样的：

public abstract class VehicleFactory {
	public abstract Moveable create();
}

具体工厂：
代码就是这样简单而美好。而它有一个具体的实现工厂类：

public class BroomFactory extends VehicleFactory {

	@Override
	public Moveable create() {
		return new Broom()；
	}
}

这个具体的实现工厂告诉我们，这里可以通过 create() 方法来创建一个 Broom
对象。
我们可以这样来理解他们的关系：有一个大的工厂它就是 VehicleFactory，
VehicleFactory工厂里又有很多生产车间，其中有一个就是 BroomFactory。我
们的具体产品都是通过这些生产车间来负责生产的
们的具体产品都是通过这些生产车间来负责生产的。
抽象产品接口：
说到了产品，我们可以先试想一下这些具体的产品都会有什么样的性质。我们可以这
样来定义它们：

public interface Moveable {
	public void run();
}

具体产品：
嗯，这是一些可以run(移动)的产品。就 BroomFactory 生产车间而言，它负责生
产 Broom。这个 Broom 是具有 Moveable 的属性。那么它的实现可以这样来
写：

public class Broom implements Moveable {

    @Override
    public void run() {
    System.out.println("我是Broom.我在飞...");
    }

}

功能测试：
我们有工厂，并且知道了工厂要生产的产品了。那么我们就来生产一个 Broom 来试
试吧：

VehicleFactory factory = new BroomFactory();
Moveable moveable = factory.create();
moveable.run();

这样我就生产了一个 Broom 了。是不是 so easy？

**注意：**厂方法模式中我们把生成产品类的时间延迟，就是通过对应的工厂类来生成对应的产品类，在这里我们就可以实现“开发-封闭”原则，无论加多少产品类，我们都不用修改原来类中的代码，而是通过增加工厂类来实现。但是这还是有缺点的，如果产品类过多，我们就要生成很多的工厂类。假如我们要实现的产品接口不止一个，也就是有多个产品接口，不同产品接口有对应的产品族。什么是产品族呢？简单的理解就是，不同牌子产的车里面会有跑车类型，家庭类型，商用类型等的车，不同牌子的车的跑车类型的车可以组成一个产品族。对于这种情况我们可以采用抽象工厂模式。

抽象工厂模式(Abstract Factory Pattern)

从上面的工厂方法中的结构图中，我们可以看到其中的具体工厂A和B是两个完全独立的。两者除了都是抽象工厂的子类，没有任何其他的交集。但是，如果我们有这样一个需求：具体工厂A和B需要生产一些同类型的不同产品。那么我们就可以试试抽象工厂模式。

我们来看看抽象工厂模式是怎么定义的：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类。同样在下面的结构图中，我们可以更好地解释这一定义。我们的抽象工厂中包含一系列的去构造一个抽象产品的方法，而具体产品的实现则是放在了具体工厂（图中的A和B）中进行。

现在我们看看代码中是如何实现的。
抽象工厂：

public abstract class AbstractFactory {

    public abstract Flyable createFlyable();
    
    public abstract Moveable createMoveable();
    
    public abstract Writeable createWriteable();
}

具体工厂：
从抽象工厂的代码中也可以看出，抽象工厂只是去“生产”一些抽象的东西。有点类似
于底层机制的感觉。现在我们来看看具体工厂的实现。

public class Factory1 extends AbstractFactory {

    @Override
    public Flyable createFlyable() {
    	return new Aircraft();
    }
    
    @Override
     public Moveable createMoveable() {
    	return new Car();
    }
    
    @Override
    public Writeable createWriteable() {
    	return new Pen();
    }

}

抽象产品接口：
在具体工厂里，我们就可以生产一些具体的产品了。就是这里的Aircraft、Car、
Pen。抽象的产品接口如下。

public interface Flyable {

public void fly(int height);
 }

具体产品：
具体的产品则是要去实现这个接口，并实现其中的方法，如下：

public class Aircraft implements Flyable {
	
    	@Override
    	public void fly(int height) {
    	 System.out.println("我是一架客运机，我目前的飞行高度为：" + height + "千米。");
    	}
	
	}

功能测试：

有了这些东西，那么我们就来好好生产一些产品吧。

public class FactoryTest {

     public static void main(String[] args) {
	    AbstractFactory factory = new Factory1();
	    Flyable flyable = factory.createFlyable();
	    flyable.fly(1589);
	    
	     Moveable moveable = factory.createMoveable();
	    moveable.run(87.6);
	    
	    Writeable writeable = factory.createWriteable();
	    writeable.write("Hello World.");
    }
}

现在让我们来看一下，结果是否跟我们想的一样吧。

总结

以上就是工厂模式的基本实现和详细说明。包括了简单工厂模式、工厂方法模式、抽
象工厂模式。我们可以基于需求来选择合适的工厂模式。
其实工厂模式也是抽象工厂的一种特殊模式，只有一个产品时是工厂模式一个工厂生产一个产品。抽象工厂其实就是一个工厂实现类去实现多个相同种类的产品，例如交通工具工厂，动物工厂等。由于工厂模式每要生产一个新产品就要新增一个新工厂，而抽象工厂每新增一个新产品只需要对应的种类接口就可以了，只有在新增产品种类时才需要新增具体的工厂类。
简而言之简单工厂在出现新产品时需要改动工厂类代码，这样不符合“开闭原则”，工厂模式则符合了“开闭原则”，但是在产品过多时代码过于繁琐，而抽象工厂则更加简洁。

更好的方案还可以在工厂模式中使用反射来创建对象，ioc就是采用该方案

public class Factory {
    
	    public static Object getInstance(Class clazz) {
	    	Object object = null;
		    try{
		        object = Class.forName(clazz.getName()).newInstance();
		    }catch(ClassNotFoundException|InstantiationException|IllegalAccessException ex){
		        ex.printStackTrace();
		    }
		    return object;
		  
	    }
	  
     }

代理模式

代理(Proxy)是一种设计模式,提供了对目标对象另外的访问方式;即通过代理对象访问目标对象.这样做的好处是:可以在目标对象实现的基础上,增强额外的功能操作,即扩展目标对象的功能.这里使用到编程中的一个思想:不要随意去修改别人已经写好的代码或者方法,如果需改修改,可以通过代理的方式来扩展该方法
举个例子来说明代理的作用:假设我们想邀请一位明星,那么并不是直接连接明星,而是联系明星的经纪人,来达到同样的目的.明星就是一个目标对象,他只要负责活动中的节目,而其他琐碎的事情就交给他的代理人(经纪人)来解决.这就是代理思想在现实中的一个例子
用图表示如下:

代理模式的关键点是:代理对象与目标对象.代理对象是对目标对象的扩展,并会调用目标对象

静态代理

静态代理在使用时,需要定义接口或者父类,被代理对象与代理对象一起实现相同的接口或者是继承相同父类或者是继承相同父类.
下面举个案例来解释:
模拟保存动作,定义一个保存动作的接口:IUserDao.java,然后目标对象实现这个接口的
方法UserDao.java,此时如果使用静态代理方式,就需要在代理对象(UserDaoProxy.java)中也实现IUserDao接口.调用的时候通过调用代理对象的方法来调用目标对象.
需要注意的是,代理对象与目标对象要实现相同的接口,然后通过调用相同的方法来调用
目标对象的方法
代码示例:
接口:IUserDao.java

public interface IUserDao {
void save();
}

目标对象:UserDao.java

public class UserDao implements IUserDao {
    public void save() {
    	System.out.println("----已经保存数据!----");
    }
}

代理对象:UserDaoProxy.java

public class UserDaoProxy implements IUserDao{
    //接收保存目标对象
    private IUserDao target;
    public UserDaoProxy(IUserDao target){
    	this.target=target;
    }
    public void save() {
	    System.out.println("开始事务...");
	    target.save();//执行目标对象的方法
	    System.out.println("提交事务...");
    }
}

测试类:App.java

public class App {
public static void main(String[] args) {
	//目标对象
	UserDao target = new UserDao();
	//代理对象,把目标对象传给代理对象,建立代理关系
	UserDaoProxy proxy = new UserDaoProxy(target);
	proxy.save();//执行的是代理的方法
	}
}

我们也可以通过继承UserDao的放式来实现静态代理

public class UserDaoProxy implements UserDao{
	    public void save() {
		    System.out.println("开始事务...");
		    super.save();//执行目标对象的方法
		    System.out.println("提交事务...");
	    }
    }

这样调用时直接调用代理类就可以了。

静态代理总结:
优点：可以做到在不修改目标对象的功能前提下,对目标功能扩展.
缺点:因为代理对象需要与目标对象实现一样的接口,所以会有很多代理类,类太多.同
时,一旦接口增加方法,目标对象与代理对象都要维护.后者可以使用继承的方式避免。

如何解决静态代理中的缺点呢?答案是可以使用动态代理方式

动态代理

代理对象的生成,是利用JDK的API,动态的在内存中构建代理对象(需要我们指定创建
代理对象/目标对象实现的接口的类型)
动态代理也叫做:JDK代理,接口代理

JDK中生成代理对象的API代理类所在包:java.lang.reflect.Proxy

JDK实现代理只需要使用newProxyInstance方法,但是该方法需要接收三个参数,完整的写法是:
static Object newProxyInstance(ClassLoader loader, Class[] interfaces,InvocationHandler h )
注意该方法是在Proxy类中是静态方法,且接收的三个参数依次为:

• ClassLoader loader,:指定当前目标对象使用类加载器,获取加载器的方法是固定
  的
• Class[] interfaces,:目标对象实现的接口的类型,使用泛型方式确认类型
• InvocationHandler h:事件处理,执行目标对象的方法时,会触发事件处理器的方
  法,会把当前执行目标对象的方法作为参数传入

代码示例:
接口类IUserDao.java以及接口实现类,目标对象UserDao是一样的,没有做修改.在这个
基础上,增加一个代理工厂类(ProxyFactory.java),将代理类写在这个地方,然后在测试
类(需要使用到代理的代码)中先建立目标对象和代理对象的联系,然后代用代理对象的
中同名方法
代理工厂类:ProxyFactory.java

/**
* 创建动态代理对象
* 动态代理不需要实现接口,但是需要指定接口类型
*/
public class ProxyFactory{
    //维护一个目标对象
    private Object target;
    public ProxyFactory(Object target){
    	this.target=target;
    }
    //给目标对象生成代理对象
    public Object getProxyInstance(){
    	return Proxy.newProxyInstance(target.getClass().getClassLoader(),
    	target.getClass().getInterfaces(), 
    	new InvocationHandler() {
		    @Override
		    public Object invoke(Object proxy, Method method, Object[] args)throws Throwable {
		    	System.out.println("开始事务2");
			    //执行目标对象方法
			    Object returnValue = method.invoke(target, args);
			    System.out.println("提交事务2");
			    return returnValue;
		    }
	    } );
    }
}

测试类:App.java

public class App {
    public static void main(String[] args) {
	    // 目标对象
	    IUserDao target = new UserDao();
	    // 【原始的类型 class cn.itcast.b_dynamic.UserDao】
	    System.out.println(target.getClass());
	    // 给目标对象，创建代理对象
	    IUserDao proxy = (IUserDao) new ProxyFactory(target).getProxyInstance();
	    // class $Proxy0 内存中动态生成的代理对象
	    System.out.println(proxy.getClass());
	    // 执行方法 【代理对象】
	    proxy.save();
    }
}

代理对象不需要实现接口,但是目标对象一定要实现接口,否则不能用动态代理

Cglib代理

上面的静态代理和动态代理模式都是要求目标对象是实现一个接口的目标对象,但是有时候目标对象只是一个单独的对象,并没有实现任何的接口,这个时候就可以使用以目标对象子类的方式类实现代理,这种方法就叫做:Cglib代理Cglib代理,也叫作子类代理,它是在内存中构建一个子类对象从而实现对目标对象功能的扩展.
JDK的动态代理有一个限制,就是使用动态代理的对象必须实现一个或多个接口,如果想代理没有实现接口的类,就可以使用Cglib实现.
Cglib是一个强大的高性能的代码生成包,它可以在运行期扩展java类与实现
java接口.它广泛的被许多AOP的框架使用,例如Spring AOP和synaop,为他们提
供方法的interception(拦截)
Cglib包的底层是通过使用一个小而块的字节码处理框架ASM来转换字节码并生成新的类.不鼓励直接使用ASM,因为它要求你必须对JVM内部结构包括class文件的格式和指令集都很熟悉.
Cglib子类代理实现方法:

1. 需要引入cglib的jar文件,但是Spring的核心包中已经包括了Cglib功能,所以直接引入
   pring-core-3.2.5.jar即可.
2. 引入功能包后,就可以在内存中动态构建子类
3. 代理的类不能为final,否则报错
4. 目标对象的方法如果为final/static,那么就不会被拦截,即不会执行目标对象额外的业
   务方法.

代码示例:
目标对象类:UserDao.java

	//目标对象,没有实现任何接口
    public class UserDao {
        public void save() {
    	   	 System.out.println("----已经保存数据!----");
        }
    }

Cglib代理工厂:ProxyFactory.java
Cglib子类代理工厂

//对UserDao在内存中动态构建一个子类对象
public class ProxyFactory implements MethodInterceptor{
    //维护目标对象
    private Object target;
    public ProxyFactory(Object target) {
    this.target = target;
    }
    //给目标对象创建一个代理对象
    public Object getProxyInstance(){
	    //1.工具类
	    Enhancer en = new Enhancer();
	    //2.设置父类
	    en.setSuperclass(target.getClass());
	    //3.设置回调函数
	    en.setCallback(this);
	    //4.创建子类(代理对象)
	    return en.create();
    }
    @Override
    public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
	    System.out.println("开始事务...");
	    //执行目标对象的方法
	    Object returnValue = method.invoke(target, args);
	    System.out.println("提交事务...");
	    return returnValue;
    }
}

测试类:

public class App {
    @Test
    public void test(){
	    //目标对象
	    UserDao target = new UserDao();
	    //代理对象
	    UserDao proxy = (UserDao)new ProxyFactory(target).getProxyInstance();
	    //执行代理对象的方法
	    proxy.save();
    }
}

在Spring的AOP编程中:
如果加入容器的目标对象有实现接口,用JDK代理
如果目标对象没有实现接口,用Cglib代理