反射是Java实现模块化的一个非常基础的功能，通过加载类的字节码，然后动态的在内存中生成对象。也是深入Java 研究的第一个高级主题。关于加载器和字节码部分的内容，可以参见本博的 《java Class和加载机制精华一页纸》
Spring 框架基础的Ioc就是采用了反射的功能，实现了框架。
1、反射
I、反射操作经典步骤
一、获取 Class对象
a、最常用的就是 Class.forName(className)
b、如果知道类名字，直接通过类获取 String.class
c、如果已有一个对象 object.getClass
二、获取 Method对象
a、通过Class对象的getdeclaredMethods 获取所有方法
b、通过名字和参数类型列表，获取具体的方法getdeclaredMethod
三、实例化该Class的对象
Class.newInstance
四、调用方法
Method.invoke(newobject,new Object[]{parmalist}
II、反射的作用
反射是实现抽象的一个基础设施。单个应用内的模块化和解耦, 大家都比较熟悉, 比如 面向接口编程, 工厂模式等等。
iterface a = Factory.create;
在Factory 里面,我们是知道这个具体的实现类的。
但如果是应用模块之间呢, 不同人或者团队开发的, 商量好名字？ 如果 名字改变后呢？
这样耦合性太强, 每次修改都会要带来代码重新修改和编译。
反射正是可以解决这个问题的工具。静态编译时, 并不需要知道具体的名字；在加载时, 通过传入名称参数, 获取到这个类
比如, 配置文件中配置了 具体实现类的名字, 只要在一个ClassPath下,就可以加载到具体的实现类。
Class c = Class.forName( param ); // 此处param可以是加载文件\其他应用传入的参数等等
iterface a = c.newInstance();
这个解耦套路,就是 传统的框架 套路
2、传统模块间解耦框架 - 依赖查找(DL)
依赖查找, 有个最经典的例子就是 JNDI , JavaEE 就是通过这个实现模块间对象的访问, 比如EJB, 下面是 tomcat下一个依赖查找的例子
I、context or server 配置文件
type="javax.sql.DataSource" auth="Container"
driverClassName="com.mysql.jdbc.Driver"
maxActive="4000"
maxIdle="60"
maxWait="15000"
url="jdbc:mysql://localhost:3306/mysql?useUnicode=true&characterEncoding=UTF-8"
username="root"
password="root"/>
II、代码中依赖查找
Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/DefaultDS");
III、依赖查找的问题
依赖查找的关键问题是 对代码侵入性强, 带来的结果就是 模块集成、单元测试等等工作很难操作, 比如测试一个EJB调用的代码, 必须要有完整的 Web框架, 要配置好基础设施；而 这段代码只是要测试自己的逻辑和接口。
3、轻量级模块间解耦框架 - 依赖注入(DI)/控制反转(Ioc)
这两个概念自从Spring横空出世以后, 一直抄的非常火热。先解释一下两个名词
依赖注入：是从应用角度出发, 需要的对象是从 外面注入进来的, 属于被动接受对象；而不像传统的 依赖查找, 主动的去查找对象。
控制反转: 是从框架和容器的角度出发, 创建对象的工作, 由应用 让渡给 容器来完成, 对象间的依赖, 也都由容器完成。
依赖注入/控制反转,看起来很神奇, 其实,如果遵循 开发的几大原则, 面向接口、职责单一、接口隔离、开放封闭等(可以参照本博《设计模式 精华一页纸》),就会发现, 这是一种比较自然和优雅的架构设计。
传统的依赖查找,虽然解开了模块间的耦合，但他违背了职责单一的要求，对于 应用而言, 只需要了解和调用 接口中的方法, 而查找这个工作不应该放在应用中。所以，可以对查找这个过程进行封装。
Object o = Lookup.get(xxx);
-- 这里的 Lookup 封装了对象的查找过程
再进一步封装和解耦，查找对象的过程对应用彻底屏蔽隔离、在应用的代码中不再出现 查找的代码。要完成这个工作
a、 首先，查找获取的对象 要设置到 使用该对象的目标对象的应用代码中, 也就是所谓的 注入工作
b、 其次，要完成注入工作，要么 把目标对象的引用传递给框架, 要么目标对象本身就是框架创建的
c、 从解耦、隔离的角度看, 框架创建管理对象更符合要求。
框架管理对象的生命周期、提供对象的注入工作。
......
Spring Ioc 框架就是在这个基础上产生了。
4、Spring Ioc 框架
从上面的讨论, 可以了解, 对象都交由框架管理和构造, 所以、首先要有对象的管理容器；其次要有注入的接口，实现装配工作。
I、Bean 工厂/容器
某种角度上,Spring Ioc就是一个对象容器, 依赖注入这些只是提供的功能而已
public interface BeanFactory{
Object getBean(String name) throws BeansException
Object getBean(String name, Class requiredType)throws BeansException
boolean containsBean(String name)
boolean isSingleton(String name)throws NoSuchBeanDefinitionException
String[] getAliases(String name)throws NoSuchBeanDefinitionException
}
四级接口
BeanFactory作为最基础的接口,只提供了基本功能。
秉着 接口隔离的设计原则, 从BeanFactory开始的继承体系
二级接口 AutowireCapableBeanFactory ListableBeanFactory HierarchicalBeanFactory
分别对应 自动装配 Bean工厂 ： 作用是不在Spring(主要是 ApplicationContext)中管理的对象, 如果在应用中用到了,Spring 无法注入，比如如果用到Tomcat已存在的对象,通过这个工厂把 这些对象引入并注入应用对象。
迭代Bean的 Bean工厂 ： 提供对容器中的Bean访问功能
访问父接口的 Bean工厂 ： 提供对父容器的访问功能
三级接口 ConfigurableBeanFactory ：叠加配置功能(是否单例、范围、Bean依赖等等)
四级接口 ConfigurableListBeanFactory ： 大合集功能的 接口, 继承之前面的接口
第一个默认的实现类 DefaultListableBeanFactory
一个比较有意思的问题： BeanFactory 和 FactoryBean 的区别？
这其实是两个完全不同层次的内容
BeanFactory 是 Ioc 容器的接口,管理Bean的核心接口
FactoryBean 则是 适配 第三方应用的一个接口, 提供了对第三方Bean的适配, 以便更好的集成到Spring中来
通过工厂Bean，应用不需要自己写适配类去装配其他应用
org.springframework.jndi.JndiObjectFactoryBean -- 提供JNDI查找的对象
org.springframework.orm.hibernate.LocalSessionFactoryBean -- 提供Hibernate SessionFactory
org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean -- 提供JDO PersistenceManagerFactory的
org.springframework.aop.framework.ProxyFactoryBean -- 获取AOP的动态代理，实现AOP切面功能
org.springframework.transaction.interceptor.TransactionProxyFactoryBean -- 创建事务代理
org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean -- EJB业务接口
...
org.springframework.remoting.caucho.HessianProxyFactoryBean -- Hessian 远程协议的代理
org.springframework.remoting.caucho.BurlapProxyFactoryBean -- Burlap远程协议的代理
II、Bean的生命周期
容器托管了 Bean的创建, 所以容器需要负责管理 Bean的生命周期。
a、生命周期
实例化 -> 设值注入 -> 设置Bean ID -> 设置工厂 -> 设置上下文 -> 初始化(开始\初始化\结束)
正常构建Bean的这些过程, 不需要应用介入。如果有特殊需要介入的地方。Spring开放了二次接口。
如果需要在构造对象的时候提供 初始化和 销毁时 额外处理的能力
方法一：Spring提供了回调接口 BeanNameAware| ApplicationContextAware | BeanPostProcessor | InitializingBean | BeanPostProcessor | DisposableBean 等等对应不同的构造阶段二次接口
org.springframework.beans.factory.InitializingBean 该接口提供了对象构造后 afterProperiesSet() throws Exception 方法
org.springframework.beans.fatory.Disposable 该接口提供了一个对象销毁后调用的 destory() throws Exception 方法
@PostConstruct 注解 | @PreDestory 初始化调用和销毁调用
方法二：Spring 可以指定属性配置
这样，在引入第三方组件时，可以不用依赖Spring容器，第三方组件不需要修改代码，或者为Spring写适配器
也可以配置全局的 init-method/destroy-method 方法
方法三：Spring提供的Bean工厂接口，Bean实现该接口，可以获取Bean工厂的引用，可以获取对其他Bean的引用，实现生命周期干预
org.springframework.beans.factory.BeanFactoryAware 该接口提供一个 setBeanFactory(BeanFactory beanFactory) throws BeanException
如何选择？
如果希望解耦Spring 框架, 则可以使用 方法二 指定属性, 这样配置方法干预初始化和销毁；否则建议使用 注解
b、作用域
singlton - 一个Spring容器对应一个 对象
prototype - 每获取一个对象
request | session | gloabl - Web应用的作用域，每作用域一个对象
默认是 singlton 作用域
Web应用 DispatchServlet 会默认管理作用域，默认是request
c、创建和销毁
何时被创建？
默认是随容器启动创建
可以配置为 lazy-init="true" 获取时创建
何时被销毁？
singlton, 在容器关闭时销毁，平时一直驻留
prototype 销毁由应用管理
- 因为只有 singlton的 对象才会进入 Bean容器工厂的ConcurrentHashMap 缓存。这也是为什么 prototype 类型的对象, 无法进行销毁回调, 因为对象的控制权交给了应用
III、 应用上下文（org.springframework.context.ApplicationContext）
工厂接口提供Bean管理的核心功能, 如果要把这个工厂应用到具体项目中, 还需要很多基础设施, ApplicationContext就是这个功能合集。
a、继承了Bean工厂的功能,继承了 ListableBeanFactory | HierarchicalBeanFactory
b、提供资源的管理，主要是加载各种配置文件
c、国际化信息，主要是各种信息的国际化
通过委托给代理类 ResourceBundleMessageSource实现国际化
d、提供事件管理
继承自Java自带的事件分发
事件ApplicationEvent -> 继承 EventObject
监听者 ApplicationListener -> 继承 EventListener
提供了 ApplicationEventPublisher 事件管理器(分发)
具体参见本博 《java 观察者、事件机制 到Spring 事件分发机制》
e、lifycycle 生命周期管理
容器的生命周期管理提供 Lifecycle 接口, 提供给任何实现 该接口的Bean, 通过LifecycleProcessor 执行回调接口, 可以和容器的生命周期管理同步。
提供 start | stop | isRunning | onRefresh 等回调接口
常用的容器实现对象
ClassPathXmlApplicationContext
FileSystemXmlApplicationContext
XmlWebApplicationContext
5、Spring Ioc实例
I、基本使用 设值和构造子
undefinedundefined
undefinedundefined
设值是通过 setter 方式注入；构造子按照顺序注入
II、集合装配
子节点有 (可嵌套）
成员有
成员比较简单，就是
value a
value b
III、工厂装配
-- 静态工厂 static
-- 动态工厂 new
IV、SPEL表达式
#{xxx} 其实是一种占位替换表达式语法, 类似的有很多比如 Freemarker 的${}, angular JS的 {{}}, 支持对内存对象的访问和简单表达式操作, 这些语法也很类似
常量 #{xx} 等同于 xx 常量一般直接用的很少
引用 #{xxx.xxx} -- 属性 #{xxx.getxxx()} -- 方法
静态属性 #{T(ClassXXX).xxx}
各种运算(算术|逻辑|正则) #{1+2} #{a == b && b == c}
V、自动装配
byName -- 根据Bean名称和属性名称进行匹配 缺点是名称要一致，如果多个名称类似，就要避开重复
byType -- 根据Bean类型和属性类型进行装配 缺点是不能存在相同类型的多个bean（解决方法，首选bean，排除其他bean）
constructor -- 把具有相同类型的 type 构造到属性中
autodetect -- 首先尝试 constuctor 装配，失败采用 byType
指定单个Bean autowire="byName"
指定全局 default-autowire
开启自动装配
VI、注解
a、注入
@Autowired 实现 构造和设置注入
@Qualifier("guitar") 指定Bean注入,甚至可以自定义 注解
@Inject -- 使用JCP的Inject注解
b、bean定义
@Component -- 通用构造性注解
@Controller -- Spring MVC Controller
@Repository -- 标记为数据仓库
@Service -- 标记为服务
经过测试发现，XML手工配置的 注入，会覆盖 注解注入的值，应该Spring的顺序最后是手工
c、用Spring配置类来替代注入的工作
// 定义全局文件的 Beans 测试的时候发现，SpringConfig 类，Spring使用了CGlib(asm) 技术重新处理了字节码
// 主要原因是，Spring 并不是直接 调用方法返回对象的，比如如下 duke() 方法，Spring会拦截，针对单例的情况
// Spring 会从自己的上下文返回一个已经存在的对象
@Configuration
public class SpringConfig {
// 定义一个名为 duke 的Bean
@Bean
public Performer duke(){
return new Juggler();
}
@Bean
public Instrument guitar(){
return new Guitar(0);
}
@Bean
public Performer kenny(){
Instrumentalist kenny = new Instrumentalist();
kenny.setSong("aaa");
kenny.setInstrument(guitar());
return kenny;
}
}
使用 Java 配置的问题是，SpringConfig 就相当于facade 门面的实现，使用了 Spring的 Context 来管理对象的生命周期。这种方式，对象间的依赖关系还是硬编码到了代码中。
