Spring源码学习笔记(十一、阶段总结)
学了一段时间的Spring源码,有些感触,虽然谈不上感触颇深但也有些体会,今天我把一些个人的感触记下来(才读了冰山一角,哈哈哈哈哈哈)。
1、面向接口编程:
哎,这其实没啥好说的,这不是常态么。
但我个人认为有扩展可能的程序才需要定义接口,向那些短期内不会变化或变化维度过大,我个人认为最好不要定义接口吧(仅针对业务开发)。
因为你根本不知道需求会怎么变,你完全可以之后再重构,持续重构不香嘛。
当然如果是框架开发的话,需求还是比较明确的,使用面向接口编程还是很香的。
2、最小知道原则:
通过阅读Spring源码后,我发现很多关键且通用的函数时无参的居多。
就比如Spring的核心refresh函数,其内部很多关键流程的代码就是无参的,有的话也只是一个factory,说明Spring封装做的非常好,只要把bean实例化出来后,很多东西就能够通过属性值来获取了。
1 @Override 2 public void refresh() throws BeansException, IllegalStateException { 3 synchronized (this.startupShutdownMonitor) { 4 // Prepare this context for refreshing. 5 prepareRefresh(); 6 7 // Tell the subclass to refresh the internal bean factory. 8 ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); 9 10 // Prepare the bean factory for use in this context. 11 prepareBeanFactory(beanFactory); 12 13 try { 14 // Allows post-processing of the bean factory in context subclasses. 15 postProcessBeanFactory(beanFactory); 16 17 // Invoke factory processors registered as beans in the context. 18 invokeBeanFactoryPostProcessors(beanFactory); 19 20 // Register bean processors that intercept bean creation. 21 registerBeanPostProcessors(beanFactory); 22 23 // Initialize message source for this context. 24 initMessageSource(); 25 26 // Initialize event multicaster for this context. 27 initApplicationEventMulticaster(); 28 29 // Initialize other special beans in specific context subclasses. 30 onRefresh(); 31 32 // Check for listener beans and register them. 33 registerListeners(); 34 35 // Instantiate all remaining (non-lazy-init) singletons. 36 finishBeanFactoryInitialization(beanFactory); 37 38 // Last step: publish corresponding event. 39 finishRefresh(); 40 } 41 42 catch (BeansException ex) { 43 if (logger.isWarnEnabled()) { 44 logger.warn("Exception encountered during context initialization - " + 45 "cancelling refresh attempt: " + ex); 46 } 47 48 // Destroy already created singletons to avoid dangling resources. 49 destroyBeans(); 50 51 // Reset 'active' flag. 52 cancelRefresh(ex); 53 54 // Propagate exception to caller. 55 throw ex; 56 } 57 58 finally { 59 // Reset common introspection caches in Spring's core, since we 60 // might not ever need metadata for singleton beans anymore... 61 resetCommonCaches(); 62 } 63 } 64 }
这点和推崇的充血模型还是比较像的,这种模型的开发方式可以让你在不了解系统整体的情况下,可以快速知道相关模块的业务逻辑。
当然这只适用于具有一定规模的系统,如果是小项目还是用贫血模型比较舒服,开发起来比较简单。
3、设计模式的灵活运用:
哎,这点就不用说了吧,人尽皆知了,哈哈哈哈。
设计模式这个东西也需要你有长期的开发经验才能更深层次的体会。
4、接口定义:
emmmmmmm,我其实想说单一职责的,但这个好像大伙都知道哦。
Spring的接口定义是非常简单的,一个接口该干什么就干什么,没有多余的定义,而需要扩展的话会再次定义。
如BeanFactory就是定义bean的相关操作,对父容器的扩展是通过HierarchicalBeanFactory接口来定义的。
这里要学学,而不是一开始就把接口定义的很模糊,然后往里面加一大堆东西,哈哈哈哈哈哈。
5、解决问题思路:
循环依赖:
循环依赖就是A依赖B,B又依赖A;因为在实例化A的时候需要用到B,所以肯定会先去把B实例化好,然后又发现B要实例化的时候又需要B,这样就形成了一个死循环。
既然会出现死循环,那么我们要解决的问题就是找到死循环的退出条件,这样循环依赖的问题不就迎刃而解了嘛(这就是解决问题的思路)。
那么Spring是如何解决循环依赖的呢,首先我们想想如果两个bean都是通过构造函数注入的话,肯定就是不行的,因为这样两个bean就都没办法实例化了,拿不到对方的对象。那么我们能不能先值注入只完成了实例化的bean呢,当然可以,而Spring也是这样做的。
Spring是提前暴露刚完成构造函数注入而未完成其它步骤(如setter注入)的bean来解决循环依赖的问题,采用了三级缓存实现,即singletonObjects、earlySingletonObjects和singletonFactories。
6、等等等等。。。。。。。