在上节中，谈了一下个人关于Bean容器的一些浅陋认识(不对的地方还望谅解)。本节中，我们将探讨设计一个Bean容器，并尝试设计一些稳定基本类或接口,作为本容容器的规范(菜鸟的设计,有点夸张了). Bean容器是一个管理对象的对象，如果把Bean容器比做一台机器，那么它是如何与外部交互的呢？从上节中，可以看出容器有两点突出的职责：接收外部指令和对外提供对象，这里提到的指令是围绕Bean进行的，比如有构造对象指令，注入属性指令等，因此我们可以假定这些对象的关系结构如下：
2.1元素类型
在上节中提到了指令,并且得知指令围绕Bean进行的，换个角度看，我们可以把这些指令看作是对Bean的描述性对象,具有元素性,因此在这里我们把这这些指令性对象对象称作为Bean的定义元素，由于其具有多样性，因此在此设计一个顶级元素类
针对Bean容器的需要,定义了一些元素对象，如下表
元素名称 | 元素作用 | 备注 |
InstanceCreation | 构造描述元素 | 支持三种方式 1：工厂方法(自身静态方法构造) 2：工厂Bean构造（利用另一个对象去构造） 3：工厂方法构造 |
InjectionField
| 对象字段注入元素 | 容器在构造出实例后，将会指定的属性实施属性值注入 |
InjectionProperty | 对象属性Set注入元素 | 容器在构造出实例后，将会指定的属性实施属性值注入 |
InjectionInvocation | 对象方法调用注入元素 | 容器在构造出实例后，将会调用指定的方法实施值注入 |
InvocationInterception | 对象方法拦截描述元素 | AOP 拦截定义 1:接口代理实现AOP 2:类的改写,实现AOP |
ProxyInterfaces | 对象实现接口描述元素 | 指定Bean实现的接口 |
InstanceSingleton | 是否为单例描述元素 | 取值为：true/false |
InitializeMethodName | 初始化方法描述元素 | 对象被创建后，将调用这个方法 |
DestroyMethodName | 破坏化方法描述元素 | 容器在关闭前，将调用这个方法 |
ParentReferenceId | 继承父类Bean的注册ID | 对象被创建后，将会调用父Bean的注入 |
下图为实际开发的元素类的代码结构图
2.2参数类型
在1.8节中我们谈到了参数指令,Bean容器依据参数指令获取参数值。在我们的设计中，设计了一个基类的参数对象，其他参数指令都是从此基础上进行扩展的,代码如下图
依据容器的需要，我们将参数类型定义了以下几个类别。
1:基本类型 2:实例类型 3:类的类型 4:引用类型 5:容器类型
参数类型 | 参数描述 |
基本类型 | 包含boolean byte short int 等基本类型 |
实例类型 | 类型包含一个已经创建好的对象作为参数 |
类的类型 | 参数值为一个类，容器将依据类型构造参数值 |
引用类型 | 容器通过应用Id，在容器中查找出对象值作为参数 |
容器类型 | 方法使用了List ,Set, Map ,Array等作为参数 |
下图开发的代码结构图(蓝色框内)：
2.3参数转换
在1.8节探讨到了参数指令,容器将通过参数指令工厂依照指令内容构造出需要的参数值，但是在实际情况中，可能会出现参数值与目标注入类型不匹配,怎么办？尝试转换,如果能转换成功,那还是可以注入的。我们在容器内部设置了一些转换器，可以通过类型获得，当然也可以增加需要类型转换器，注册在容器中即可,下面我们贴出我们设计的转换器接口。
为了更好理解转换器的作用，下面给出一段容器内部使用伪代码
2.4面向接口
面向接口开发我给我们开发人员带来很大的便利。这好比数据库供应商存在多家，它们各自针对JDBC驱动接口提供各自的实现，我们的程序无须依赖具体的某家实现，只是依赖JDBC的接口，最大程序保护了程序的稳定性，即便要切换系统的数据库,也是比较容易的。依据这个思想，我们设计了一个BeanContext类和一个BeanContextFactory类，如果将来存在多种实现的时候，也不会影响到程序的变动，下面给出一段使用代码
通过以上方式开发，是必须要提供那个BEAN_CONTEXT_FACTORY，其接口代码很简单
