spring中的BeanFactory就是简单工厂模式的体现,根据传入一个惟一的标志来得到bean对象,可是否是在传入参数后建立仍是传入参数前建立这个要根据具体状况来定。以下配置,就是在类中建立一个Bean。java
<bean id="annotationlMessageServiceBean" class="com.cn.service.impl.AnnotationMessageServiceImpl"> <constructor-arg> <value>Hello ! 这是annotationlMessageServiceBean!</value> </constructor-arg> </bean>
一般由应用程序直接使用new建立新的对象,为了将对象的建立和使用相分离,采用工厂模式,即应用程序将对象的建立及初始化职责交给工厂对象。通常状况下,应用程序有本身的工厂对象来建立bean,若是将应用程序本身的工厂对象交给spring管理,那么spring管理的就不是普通的bean,而是工厂bean。算法
就以工厂方法中的静态方法为例讲解一下:spring
import java.util.Random; public class StaticFactoryBean { public static Integer createRandom() { return new Integer(new Random().nextInt()); } }
建立一个config.xml配置文件,将其归入Spring容器来管理,须要经过factory-method指定静态方法名称数据库
<?xml version="1.0" encoding="UTF-8" ?> <beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.springframework.org/schema/beans" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd" default-autowire="byName"> <bean id="random" class="com.cn.service.StaticFactoryBean" factory-method="createRandom" scope="prototype" /> <!-- createRandom方法必须是static的,才能找到 --> </beans>
测试:apache
public static void main(String[] args) { // 建立容器对象(Bean的工厂),IOC容器 = 工厂类+ config.xml DefaultListableBeanFactory factory = new DefaultListableBeanFactory(); // 获得容器建立的对象 XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory); reader.loadBeanDefinitions(new ClassPathResource("config.xml")); System.out.println("我是IT学习者建立的实例:" + factory.getBean("random")); }
保证一个类仅有一个实例,并提供一个访问它的全乎访问点。spring中的单例模式完成了后半句话,即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例,这是由于spring管理的是任意的java对象。设计模式
核心提示点:Spring下默认的bean均为singleton,能够经过singleton="true|false"或者 scope="?"来指定session
在spring的Aop中,使用的Advice(通知)来加强被代理类的功能。Spring实现这一AOP功能的原理就使用代理模式(一、JDK动态代理。二、CGLib字节码生成技术处理。)对类进行方法级别的切面加强,即,生成被代理类的代理类,并在代理类的方法前,设置拦截器,经过执行拦截器重的内容加强了代理方法的功能,实现面向切面变成。mybatis
Adapter类接口:Targetapp
public interface AdvisorAdapter { boolean supportsAdvice(Advice advice); MethodInterceptor getInterceptor(Advisor advisor); }
MethodBeforeAdviceAdapter类,Adapter框架
public class MethodBeforeAdvisorAdapter implements AdvisorAdapter, Serializable { private static final long serialVersionUID = 5727339338103580037L; public boolean supportsAdvice(Advice advice) { return (advice instanceof MethodBeforeAdvice); } public MethodInterceptor getInterceptor(Advisor advisor) { MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice(); return new MethodBeforeAdviceInterceptor(advice); } }
假设一个场景:项目须要链接多个数据库,并且不一样的用户在每次访问中根据须要回去访问不一样的数据库。以往的操做都是在spring或mybatis框架中配置一个数据源,于是sessionFactory的dataSource属性老是指向这个数据源而且恒定不变,全部DAO在使用sessionFactory的时候都是经过这个数据源访问数据库。可是如今,因为项目的须要。DAO在访问sessionFactory的时候都不得不在多个数据源中来回切换,问题就出现了:如何让sessionFactory在执行数据持久化的时候,根据用户的需求可以动态切换不一样的数据源?咱们能不能在spring的框架下经过少许修改获得解决?是否有什么设计模式能够利用呢?
首先想到在spring的applicationContext中配置全部的dataSource。这些dataSource多是各类不一样类型的,好比不一样的数据库:Oracle、SQL Server、MySQL等,也多是不一样的数据源:好比apache提供的org.apache.commons.dbcp.BasicDataSource、spring提供的org.springframework.jndi.JndiObjectFactoryBean、阿里提供的com.alibaba.druid.pool.DruidDataSource等。而后sessionFactory根据客户的每次请求,将dataSource属性设置成不一样的数据源,以到达切换数据源的目的。
spring中用到的包装器模式在类名上有两种表现:一种是类名中含有Wrapper,另外一张类名中含有Decorator。基本上都是动态地给一个对象添加一些额外的职责。
为其余对象提供一种代理以控制对这个对象的访问。从结构上来看和Decorator模式相似,但Proxy是控制,更像是一种对功能的限制。而Decorator是增长职责。
spring的Proxy模式在aop中有体现,好比JdkDynamicAopProxy和Cglib2AopProxy。
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,全部依赖于它的对象都获得通知并自动更新。
spring中Observer模式经常使用的地方是listener的实现。如ApplicationListener
定义一系列的算法,把它们一个个封装起来,而且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
spring中在实例化对象的时候用到Strategy模式在SimpleInstantiationStratrgy中有以下代码说明了策略模式的使用请了:
public Object instantiate(RootBeanDefinition beanDefinition, String beanName, BeanFactory owner) { // Don't override the class with CGLIB if no overrides. if (beanDefinition.getMethodOverrides().isEmpty()) { Constructor<?> constructorToUse; synchronized (beanDefinition.constructorArgumentLock) { constructorToUse = (Constructor<?>) beanDefinition.resolvedConstructorOrFactoryMethod; if (constructorToUse == null) { final Class<?> clazz = beanDefinition.getBeanClass(); if (clazz.isInterface()) { throw new BeanInstantiationException(clazz, "Specified class is an interface"); } try { if (System.getSecurityManager() != null) { constructorToUse = AccessController.doPrivileged(new PrivilegedExceptionAction<Constructor<?>>() { @Override public Constructor<?> run() throws Exception { return clazz.getDeclaredConstructor((Class[]) null); } }); } else { constructorToUse = clazz.getDeclaredConstructor((Class[]) null); } beanDefinition.resolvedConstructorOrFactoryMethod = constructorToUse; } catch (Exception ex) { throw new BeanInstantiationException(clazz, "No default constructor found", ex); } } } return BeanUtils.instantiateClass(constructorToUse); }else { // Must generate CGLIB subclass. return instantiateWithMethodInjection(beanDefinition, beanName, owner); } }
定义一个操做中的算法的骨架,而将一些步骤延迟到子类中。Template Method使得子类能够不改变一个算法的结构便可重定义该算法的某些特定步骤。
Template Method模式通常是须要继承的。这里想要探讨另外一种对Template Method的理解。spring中的JdbcTemplate,在用这个类时并不想去继承这个类,由于这个类的方法太多。可是咱们仍是想用到JdbcTemplate已有的稳定的、公用的数据库链接,那么咱们怎么办呢?那咱们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法,咱们去实现这个方法,就把变化的东西集中到这里了。而后咱们再传入这个回调对象到JdbcTemplate,从而完成了调用。这多是Template Method不须要继承的另外一种实现方式吧。
如下是一个具体的例子: JdbcTemplate中的execute方法 定义一个操做中的算法的骨架,而将一些步骤延迟到子类中。Template Method使得子类能够不改变一个算法的结构便可重定义该算法的某些特定步骤。
Template Method模式通常是须要继承的。这里想要探讨另外一种对Template Method的理解。spring中的JdbcTemplate,在用这个类时并不想去继承这个类,由于这个类的方法太多,可是咱们仍是想用到JdbcTemplate已有的稳定的、公用的数据库链接,那么咱们怎么办呢?咱们能够把变化的东西抽出来做为一个参数传入JdbcTemplate的方法中。可是变化的东西是一段代码,并且这段代码会用到JdbcTemplate中的变量。怎么办?那咱们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法,咱们去实现这个方法,就把变化的东西集中到这里了。而后咱们再传入这个回调对象到JdbcTemplate,从而完成了调用。这多是Template Method不须要继承的另外一种实现方式吧。
如下是一个具体的例子:
JdbcTemplate中的execute方法
public <T> T execute(StatementCallback<T> action) throws DataAccessException { Assert.notNull(action, "Callback object must not be null"); Connection con = DataSourceUtils.getConnection(getDataSource()); Statement stmt = null; try { Connection conToUse = con; if (this.nativeJdbcExtractor != null && this.nativeJdbcExtractor.isNativeConnectionNecessaryForNativeStatements()) { conToUse = this.nativeJdbcExtractor.getNativeConnection(con); } stmt = conToUse.createStatement(); applyStatementSettings(stmt); Statement stmtToUse = stmt; if (this.nativeJdbcExtractor != null) { stmtToUse = this.nativeJdbcExtractor.getNativeStatement(stmt); } T result = action.doInStatement(stmtToUse); handleWarnings(stmt); return result; } catch (SQLException ex) { // Release Connection early, to avoid potential connection pool deadlock // in the case when the exception translator hasn't been initialized yet. 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()); } }
完结~~~~!!!!