目录
一、前言
二、目标
三、设计
四、实现
1. 工程结构
2. beandefinition 定义
3. 单例注册接口定义和实现
4. 抽象类定义模板方法(abstractbeanfactory)
5. 实例化bean类(abstractautowirecapablebeanfactory)
6. 核心类实现(defaultsingletonbeanregistry)
五、测试
1. 事先准备
2. 测试用例
3. 测试结果
六、总结
你是否能提前预见复杂内容的设计问题？
讲道理，无论产品功能是否复杂，都有很大一部分程序员会写出一堆 if...else 来完成开发并顺利上线。这主要是原因没法预见当前的需求，发展是否长远、流量是否庞大、迭代是否迅速，所以在被催促上线的情况，不写 if...else 是不可能的！
那你说，既然 if...else 实现的这么快，还考虑数据结构、算法逻辑、设计模式、系统架构吗？当然这基本要看你的项目在可预见下能活多久，如果一个项目至少存活一年，并且在这一年中又会不断的的迭代。就像；你做了一个营销优惠券系统，在各种条件下发放各种类型的券，如果在最开始没有考虑好系统设计和架构模式，那么当活动频发、流量暴增、需求迭代下、最后你可能会挂在系统事故上！
我们在把系统设计的视角聚焦到具体代码实现上，你会有什么手段来实现你想要的设计模式呢？其实编码方式主要依托于：接口定义、类实现接口、抽象类实现接口、继承类、继承抽象类，而这些操作方式可以很好的隔离开每个类的基础功能、通用功能和业务功能，当类的职责清晰后，你的整个设计也会变得容易扩展和迭代。
接下来在本章节继续完善 spring bean 容器框架的功能开发，在这个开发过程中会用到较多的接口、类、抽象类，它们之间会有类的实现、类的继承。可以仔细参考这部分内容的开发实现，虽然并不会很复杂，但这种设计思路是完全可以复用到我们自己的业务系统开发中的。
在上一章节 《小试牛刀，实现一个简单的bean容器》 我们初步依照 spring bean 容器的概念，实现了一个粗糙版本的代码实现。那么本章节我们需要结合已实现的 spring bean 容器进行功能完善，实现 bean 容器关于 bean 对象的注册和获取。
这一次我们把 bean 的创建交给容器，而不是我们在调用时候传递一个实例化好的 bean 对象，另外还需要考虑单例对象，在对象的二次获取时是可以从内存中获取对象的。此外不仅要实现功能还需要完善基础容器框架的类结构体，否则将来就很难扩容进去其他的功能了。
鉴于本章节的案例目标，我们需要将 spring bean 容器完善起来，首先非常重要的一点是在 bean 注册的时候只注册一个类信息，而不会直接把实例化信息注册到 spring 容器中。那么就需要修改 beandefinition 中的属性 object 为 class，接下来在需要做的就是在获取 bean 对象时需要处理 bean 对象的实例化操作以及判断当前单例对象在容器中是否已经缓存起来了。整体设计如图 3-1
首先我们需要定义 beanfactory 这样一个 bean 工厂，提供 bean 的获取方法 getbean(string name)，之后这个 bean 工厂接口由抽象类 abstractbeanfactory 实现。这样使用模板模式的设计方式，可以统一收口通用核心方法的调用逻辑和标准定义，也就很好的控制了后续的实现者不用关心调用逻辑，按照统一方式执行。那么类的继承者只需要关心具体方法的逻辑实现即可。
那么在继承抽象类 abstractbeanfactory 后的 abstractautowirecapablebeanfactory 就可以实现相应的抽象方法了，因为 abstractautowirecapablebeanfactory 本身也是一个抽象类，所以它只会实现属于自己的抽象方法，其他抽象方法由继承 abstractautowirecapablebeanfactory 的类实现。这里就体现了类实现过程中的各司其职，你只需要关心属于你的内容，不是你的内容，不要参与。这一部分内容我们会在代码里有具体的体现
另外这里还有块非常重要的知识点，就是关于单例 singletonbeanregistry 的接口定义实现，而 defaultsingletonbeanregistry 对接口实现后，会被抽象类 abstractbeanfactory 继承。现在 abstractbeanfactory 就是一个非常完整且强大的抽象类了，也能非常好的体现出它对模板模式的抽象定义。接下来我们就带着这些设计层面的思考，去看代码的具体实现结果
工程源码：公众号「bugstack虫洞栈」，回复：spring 专栏，获取源码
spring bean 容器类关系，如图 3-2
图 3-2
虽然这一章节关于 spring bean 容器的功能实现与 spring 源码中还有不少的差距，但以目前实现结果的类关系图来看，其实已经具备了一定的设计复杂性，这些复杂的类关系设计在各个接口定义和实现以及在抽象类继承中都有所体现，例如：
beanfactory 的定义由 abstractbeanfactory 抽象类实现接口的 getbean 方法
而 abstractbeanfactory 又继承了实现了 singletonbeanregistry 的defaultsingletonbeanregistry 类。这样 abstractbeanfactory 抽象类就具备了单例 bean 的注册功能。
abstractbeanfactory 中又定义了两个抽象方法：getbeandefinition(string beanname)、createbean(string beanname, beandefinition beandefinition) ，而这两个抽象方法分别由 defaultlistablebeanfactory、abstractautowirecapablebeanfactory 实现。
最终 defaultlistablebeanfactory 还会继承抽象类 abstractautowirecapablebeanfactory 也就可以调用抽象类中的 createbean 方法了。
综上这一部分的类关系和实现过程还是会有一些复杂的，因为所有的实现都以职责划分、共性分离以及调用关系定义为标准搭建的类关系。这部分内容的学习，可能会丰富你在复杂业务系统开发中的设计思路。
cn.bugstack.springframework.beans.factory.config.beandefinition
在 bean 定义类中已经把上一章节中的 object bean 替换为 class，这样就可以把 bean 的实例化操作放到容器中处理了。如果你有仔细阅读过上一章并做了相应的测试，那么你会发现 bean 的实例化操作是放在初始化调用阶段传递给 beandefinition 构造函数的。
cn.bugstack.springframework.beans.factory.config.singletonbeanregistry
这个类比较简单主要是定义了一个获取单例对象的接口。
cn.bugstack.springframework.beans.factory.config.defaultsingletonbeanregistry
在 defaultsingletonbeanregistry 中主要实现 getsingleton 方法，同时实现了一个受保护的 addsingleton 方法，这个方法可以被继承此类的其他类调用。包括：abstractbeanfactory 以及继承的 defaultlistablebeanfactory 调用。
cn.bugstack.springframework.beans.factory.support.abstractbeanfactory
abstractbeanfactory 首先继承了 defaultsingletonbeanregistry，也就具备了使用单例注册类方法。
接下来很重要的一点是关于接口 beanfactory 的实现，在方法 getbean 的实现过程中可以看到，主要是对单例 bean 对象的获取以及在获取不到时需要拿到 bean 的定义做相应 bean 实例化操作。那么 getbean 并没有自身的去实现这些方法，而是只定义了调用过程以及提供了抽象方法，由实现此抽象类的其他类做相应实现。
后续继承抽象类 abstractbeanfactory 的类有两个，包括：abstractautowirecapablebeanfactory、defaultlistablebeanfactory，这两个类分别做了相应的实现处理，接着往下看。
cn.bugstack.springframework.beans.factory.support.abstractautowirecapablebeanfactory
在 abstractautowirecapablebeanfactory 类中实现了 bean 的实例化操作 newinstance，其实这块会埋下一个坑，有构造函数入参的对象怎么处理？可以提前思考
在处理完 bean 对象的实例化后，直接调用 addsingleton 方法存放到单例对象的缓存中去。
cn.bugstack.springframework.beans.factory.support.defaultsingletonbeanregistry
defaultlistablebeanfactory 在 spring 源码中也是一个非常核心的类，在我们目前的实现中也是逐步贴近于源码，与源码类名保持一致。
defaultlistablebeanfactory 继承了 abstractautowirecapablebeanfactory 类，也就具备了接口 beanfactory 和 abstractbeanfactory 等一连串的功能实现。所以有时候你会看到一些类的强转，调用某些方法，也是因为你强转的类实现接口或继承了某些类。
除此之外这个类还实现了接口 beandefinitionregistry 中的 registerbeandefinition(string beanname, beandefinition beandefinition) 方法，当然你还会看到一个 getbeandefinition 的实现，这个方法我们文中提到过它是抽象类 abstractbeanfactory 中定义的抽象方法。现在注册bean定义与获取bean定义就可以同时使用了，是不感觉这个套路还蛮深的。接口定义了注册，抽象类定义了获取，都集中在 defaultlistablebeanfactory 中的 beandefinitionmap 里
cn.bugstack.springframework.test.bean.userservice
这里简单定义了一个 userservice 对象，方便我们后续对 spring 容器测试。
cn.bugstack.springframework.test.apitest
在此次的单元测试中除了包括；bean 工厂、注册 bean、获取 bean，三个步骤，还额外增加了一次对象的获取和调用。这里主要测试验证单例对象的是否正确的存放到了缓存中。
此外与上一章节测试过程中不同的是，我们把 userservice.class 传递给了 beandefinition 而不是像上一章节那样直接 new userservice() 操作。
这里会有两次测试信息，一次是获取 bean 时直接创建的对象，另外一次是从缓存中获取的实例化对象。
此外从调试的截图中也可以看到第二次获取单例对象，已经可以从内存中获取了，如图 3-3
到这本章节的功能实现和测试验证就完成了，关于测试过程中可以再去断点调试下各个阶段类的调用，熟悉调用关系。
相对于前一章节对 spring bean 容器的简单概念实现，本章节中加强了功能的完善。在实现的过程中也可以看到类的关系变得越来越多了，如果没有做过一些稍微复杂的系统类系统，那么即使现在这样9个类搭出来的容器工厂也可以给你绕晕。
在 spring bean 容器的实现类中要重点关注类之间的职责和关系，几乎所有的程序功能设计都离不开接口、抽象类、实现、继承，而这些不同特性类的使用就可以非常好的隔离开类的功能职责和作用范围。而这样的知识点也是在学习手写 spring bean 容器框架过程非常重要的知识。
最后要强调一下关于整个系列内容的学习，可能在学习的过程中会遇到像第二章节那样非常简单的代码实现，但要做一个有成长的程序员要记住代码实现只是最后的落地结果，而那些设计上的思考才是最有价值的地方。就像你是否遇到过，有人让你给一个内容做个描述、文档、说明，你总觉得太简单了没什么可写的，即使要动笔写了也不知道要从哪开始！其实这些知识内容都来源你对整体功能的理解，这就不只是代码开发还包括了需求目标、方案设计、技术实现、逻辑验证等等过程性的内容。所以，不要只是被看似简单的内容忽略了整体全局观，要学会放开视野，开放学习视角。