概述
- 工厂模式解决的问题：解耦、创建时干预、统一管理
- 单例模式解决的问题：可以共享的资源就不要重复创建，特别是创建起来成本很高的资源，比如数据源
- 代理模式解决的问题：既不修改基类（无侵入），又可以灵活的扩展它的功能，而且这种扩展是可以复用的，比如AspectJ、CGLIB、JDK动态代理
- 观察者模式解决的问题：事件通知，比如zk节点的watch机制，比如tomcat的启动机制（创建IOC、MVC容器）
- 模板模式解决的问题：代码冗余，通过模板类+业务类作为参数解决。比如JDBCTemplate，模板方法处理 创建连接、处理异常、释放资源等操作，业务类执行自己的sql
- 策略模式解决的问题：同一类型业务的类，有很多公用的流程和方法，只是在核心方法上略有区别，为了降低代码的冗余度，单独把不同的方法抽象成一个接口，各自业务类实现自己的核心方法
- 责任链模式解决的问题：把一套流程拆分成不同的Handler，使用的时候根据业务场景拼装，可以非常灵活和低耦合的实现特定的业务流程。
工厂方法模式，
- 工厂模式的优点：解耦、统一调度和管理。
- 工厂模式的角色：工厂类、产品接口类、产品类s
简单工厂模式：通过beanID+Bean全路径生产bean（反射），具体由BeanFactory的实现类来生产。还提供默认单例缓存功能。
比如容器级别的生命周期干预、父子容器、单例模式的控制，这些都是由工厂端（IOC）来做的，如果通过new的形式创建Bean，实现起来就会更复杂。
IOC是在生产Bean的时候，check需不需要干预，check是否单例，是的话，丢到singotonObject里面去，需不需要动态代理。
BeanFactory bf = new XmlBeanFactory(new ClassPathResource("appcxt-context.xml"));
Car car=bf.getBean("car", Car.class);
单例模式
核心方法通过AbstractBeanFactory实现的
- 最开始会做一个Eagerly check，如果是单例且已经缓存，后面就不用管了，直接返回单例
- 做完一些校验之后，再加锁（this.singletonObjects 这个对象），Double Check之后，再创建Bean，创建完之后缓存在singletonObjects里面
- 创建Bean的时候加了锁，addSingleton时候也重入了该锁
public Object getSingotonByBeanName(String beanName){
Object bean=getSingleton(String beanName, boolean allowEarlyReference) ；
if(bean==null){
synchronized (this.singletonObjects) {
//双重校验
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
singletonObject = singletonFactory.createBean();
addSingleton(beanName, singletonObject);
}
return singletonObject;
}
}
}
代理模式
JDK动态代理、CGLIB代理模式、AspectJ
AspectJ 编译期代理
-JDK动态代理，CGLIB 代理，都是动态编译JDK动态代理：反射原理基于接口的方法做代理，代理类只包含接口里面的所有方法。
CGLIB： 是Encacher工具类，继承代理类，植入代理逻辑.
模板模式
解决的问题：减少冗余代码，通过模板方法+callback对象
实现方法：模板类提供模板方法，调用类接口提供自定义的通用方法，调用类作为参数，在执行完模板方法时，出发自己的业务逻辑代码
比如JDBCTemplate：封装了 获得数据库连接，处理事务，处理异常，关闭资源等等通用方法，执行完之后，调用callback的不一样的业务逻辑
public <T> T execute(StatementCallback<T> action) {
Connection con = DataSourceUtils.getConnection(getDataSource());
Statement stmt = null;
try {
Connection conToUse = con;
stmt = conToUse.createStatement();
applyStatementSettings(stmt);
Statement stmtToUse = stmt;
T result = action.doInStatement(stmtToUse);
return result;
}
catch (SQLException ex) {
JdbcUtils.closeStatement(stmt);
stmt = null;
DataSourceUtils.releaseConnection(con, getDataSource());
con = null;
throw getExceptionTranslator().translate("StatementCallback", getSql(action), ex);
}
finally {
JdbcUtils.closeStatement(stmt);
DataSourceUtils.releaseConnection(con, getDataSource());
}
}
观察者模式
- 观察者模式解决的问题：事件通知，比如zk节点的watch机制，比如tomcat的启动机制（创建IOC、MVC容器）
- 观察者模式的角色：被观察者，观察者接口（定义通知的回调方法）、具体的观察者（可能是多个）
- 原理：被观察者开放接口接受注册，当被观察者根据业务设计，在一定的时机下，触发已经注册了的观察者的通知方法
比如web容器，ContextLoaderListener注册，容器启动的时候，会根据指定的Spring配置文件，创建IOC容器。
策略模式
Spring MVC中引用了策略模式解决了不同类型的Request，可以共用DispatchServlet.doDispach()方法。
程序会根据HandlerMapping中反馈的Handler的类型来选择对于的适配器接口的实现类，最终实现不同的处理逻辑
HandlerAdapter是一个接口，所有的扩展功能类都实现这个接口的 handler()方法，这样做的好处是节省内存，用到那种类型的Handler就加载哪个Handler，而不是一股脑的全加载进来
DispatcherServlet.doDispatch
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
ModelAndView mv = null;
// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
applyDefaultViewName(processedRequest, mv);
mappedHandler.applyPostHandle(processedRequest, response, mv);
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
-
HandlerAdapter 代表的不同类型的Handler们
image
责任链模式
灵活性在于：
- 可以根据业务规则配置不同顺序的拦截器（责任链）
- 可以根据业务规则配置不同种类的拦截器（责任链）
Spring里面配置的 拦截器，按照业务的需求来按照一定的顺序自由组合起来，实现特定的业务场景
