Spring源码学习笔记（十一、阶段总结）

学了一段时间的Spring源码，有些感触，虽然谈不上感触颇深但也有些体会，今天我把一些个人的感触记下来（才读了冰山一角，哈哈哈哈哈哈）。

1、面向接口编程：

哎，这其实没啥好说的，这不是常态么。

但我个人认为有扩展可能的程序才需要定义接口，向那些短期内不会变化或变化维度过大，我个人认为最好不要定义接口吧（仅针对业务开发）。

因为你根本不知道需求会怎么变，你完全可以之后再重构，持续重构不香嘛。

当然如果是框架开发的话，需求还是比较明确的，使用面向接口编程还是很香的。

2、最小知道原则：

通过阅读Spring源码后，我发现很多关键且通用的函数时无参的居多。

就比如Spring的核心refresh函数，其内部很多关键流程的代码就是无参的，有的话也只是一个factory，说明Spring封装做的非常好，只要把bean实例化出来后，很多东西就能够通过属性值来获取了。

@Override
public void refresh() throws BeansException, IllegalStateException {
    synchronized (this.startupShutdownMonitor) {
        // Prepare this context for refreshing.
        prepareRefresh();

        // Tell the subclass to refresh the internal bean factory.
        ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

        // Prepare the bean factory for use in this context.
        prepareBeanFactory(beanFactory);

        try {
            // Allows post-processing of the bean factory in context subclasses.
            postProcessBeanFactory(beanFactory);

            // Invoke factory processors registered as beans in the context.
            invokeBeanFactoryPostProcessors(beanFactory);

            // Register bean processors that intercept bean creation.
            registerBeanPostProcessors(beanFactory);

            // Initialize message source for this context.
            initMessageSource();

            // Initialize event multicaster for this context.
            initApplicationEventMulticaster();

            // Initialize other special beans in specific context subclasses.
            onRefresh();

            // Check for listener beans and register them.
            registerListeners();

            // Instantiate all remaining (non-lazy-init) singletons.
            finishBeanFactoryInitialization(beanFactory);

            // Last step: publish corresponding event.
            finishRefresh();
        }

        catch (BeansException ex) {
            if (logger.isWarnEnabled()) {
                logger.warn("Exception encountered during context initialization - " +
                        "cancelling refresh attempt: " + ex);
            }

            // Destroy already created singletons to avoid dangling resources.
            destroyBeans();

            // Reset 'active' flag.
            cancelRefresh(ex);

            // Propagate exception to caller.
            throw ex;
        }

        finally {
            // Reset common introspection caches in Spring's core, since we
            // might not ever need metadata for singleton beans anymore...
            resetCommonCaches();
        }
    }
}

这点和推崇的充血模型还是比较像的，这种模型的开发方式可以让你在不了解系统整体的情况下，可以快速知道相关模块的业务逻辑。

当然这只适用于具有一定规模的系统，如果是小项目还是用贫血模型比较舒服，开发起来比较简单。

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、等等等等。。。。。。。