约定优于配置的一个思考

   为什么必须用IOC(DI),实际上是出于在设计上的一种关注分离观念，使得系统各部分独立演化，不相互影响，使得系统能够适应环境变化的要求。
   但是问题是：A:依赖的判定，现在依赖于XML配置文件的事先说明，大量的XML造成加载变慢，测试时虽然只关注涉及到的对象，但是全部加载了定义数据，使得速度很慢，另外XML臃肿带来的问题也不小。本来是为了简化系统的构建，但是我们除了在开发Bean的工作量，还不得不更多的维护配置。

     对IOC容器改进的想法（有待实现）：
     采用Coc（约定优于配置），这个SpringX已经先前一步了，对于明确类型的依赖关系，采用反射判断属性类型并实例化后注入。
     对于基于接口的依赖，因为没有指明具体的依赖目标类，只能通过XML说明，那么这样做就能大大简化XML配置文件，另外因为在获得“主”对象，Bean.Factory.CreateBean(TargetType.class)可以指明一个依赖注入的方向，就是针对target type的，那么IOC容器就没有必要把所有BeanDefinition导入，测试一个Bean也只加载和此Bean相关的东西，速度很快，配置也简单。
      
     不过Coc的IOC也有问题，就是我们注入不是对象而是值,如果全部采用Coc,只能初始值为0或空，也许你会说不是还有XML来指明吗?但是这样的注入值会有多少？你无法假定，这和具体的功能实现有关，根本无法假定，不过>1个或者超出100个都有可能，注定在特定情况下会使XML配置再度臃肿，虽然启动速度仍然可能很快，但是针对XML的维护量也是不少的。这样的话，我的想法是，分析一下很多时候确实需要几个初始化的固定数值注入到目标对象中，比如想初始化一个列表的大小为10，不过还有其他一些值，是依赖于运行时的，比如一个值由另外一个东东获得，那么可不可以做一个可以注入注出变量的中间地带，在另个对象的提供的数值变化后，本对象就能自动获得？即使是在初始化的时候，而提供值的对象被设计成不需要固定值初始化的， 它可以根据某些逻辑自己提供值，这样也能大大简化XML配置和BeanDeiniftion加载的情况。

    不知道其他人的想法如何？讨论一下

适用自己的才是最好的

其实在开发中有好多都是固定模式的，所以应该用约定；这样维护起来很方便；但缺点是对于新手来说这些约定太多，记着太慢！