-
setBean（）用于
委托ioc 容器创建一个bean
具体的创建Bean的过程是通过反射实现的
查看全部 -
getBean() 用于根据beanId 获取实例Bean 并 返回 Bean<br/>查看全部
-
第五步：创建 IOC 容器 IoCContainer 类，声明一个Map 类型的 beans
并创建 GET/SET 两个方法用于对Bean实例进行赋值与获取值
查看全部 -
第四步：创建LiSi，继承HumenWithCar类，并重写 hoHome 方法<br/>查看全部
-
第三步：创建 ZhangSan ，继承 HumenWithCar 类，并重写 hoHome 方法<br/>查看全部
-
第二步 ： 创建一个 HumenWithCar 类 ，关联人与车；
将该类声明为 抽象类，类中的 Car 实例通过构造方法获取
查看全部 -
第一步：声明一个 Humen 人类接口
查看全部 -
简化 IOC 业务逻辑的 三个约定
查看全部 -
实现一个自己的 IOC , 场景设计
查看全部 -
重点： Car 的 创建者是谁呢？
那就是IOC 容器，车本身不会自己创建自己，而张三这个使用者又不会创建，所以实际的 Bean 的创建由 容器本身来创建
查看全部 -
在Audi和 Buick 实现Car 的接口后，在 ZhangSan中声明 Car 的实例，在这里，Car 的实例不是有张三所创建的，将其放到构造方法中，
注意： 从代码中可知，车辆的创建和销毁已经不是 ZhangSan 所 执行的，那么也就意味着ZhangSan 失去了对对象的控制权；
那么，对象的可控制权是交给谁呢？
答案就是 IOC 容器；而这也是 IOC 中的 “控制反转”中“反转” 的真正体现
查看全部 -
改进原始的 购车计划： 将方法域中的 Audi 实例提到 成员属性所在的域中，使用 Buick 替代 Audi，这样就不需要修改 方法内的代码 <br/>查看全部
-
手动创建实例的 问题——高耦合性查看全部
-
为什么要使用IOC ？
模拟场景：回家
①我 -----> 走路 ----> 回家
②我------> 坐车 ------->回家
①、②之间的区别在于，我自己走路回家，从出发到到达目的地都是自己在执行；而②中是将自己要回家的任务交由车辆执行，自己只需要依赖于车辆（坐在车上）就可以，等车辆到达目的地，下车就可以。
由此引申出，默认情况下，我们调用一个实例时，大部分情况由自己手动创建，然后才能去达到目的；使用IOC后，只需要掌握主要的方向，将实际的操作交由容器去处理，在需要的时候调用容器返回的结果，如@Autowire注解的实例（这是基于多态的实现），便可以达到调用bean实例的目的；
不过，IOC真正的意义在于可以降低代码的耦合度；当目标人物只有一辆车时，使用IOC进行依赖注入效果并不明显，但是，如果目标人物有多辆车呢？
按照传统的做法，每一辆车都创建一个实例，奥迪 是 new Audi()，别克是 new Buick();......
这就显得很繁琐，代码也会很冗余，每一次替换车辆都会造成代码大幅度的改动，增加了工作量。
而IOC则能很好的解决这个问题，由前文中所描述的，IOC的底层依赖注入使用了类似 多态的结构，这也就意味着可以通过接口的实现或类的继承的方式来通过进行动态调用 车辆的实例，而不需要修改整行的实例对象代码。
例如：奥迪和别克都实现了车的接口，那么就可以通过多态的形式，将车类的共性方法或属性放在父类中，独有的各自声明，当需要调用时，由容器返回父类的实例，再通过泛型的方式声明当前调用的是哪一种车？然后返回实例。
注意：
Car audi = new Audi();
多态中，返回的 "audi" 虽然是父类变量的引用，但是指向的是子类对象。
可以用它来调子类对象的方法或属性
泛型方式:
Car<Audi> audi = new Car<Audi>();这里做了进一步的解释，有利于理解。实际上容器不会这么做；而是
Car audi = new Audi();
Car buick = new Buick();
这便是底层的一部分操作的解读
查看全部 -
什么是IOC查看全部
举报