标签:style blog color io 使用 文件 数据 div sp
IoC反转控制,
举个反例:
1 //数据操作类 2 public class DataBase 3 { 4 //向数据库中存储数据 5 public void saveDB() 6 { 7 } 8 } 9 //业务逻辑类 10 public class Business 11 { 12 //定义数据接口 13 private DataBase db = new DataBase(); 14 //数据保存 15 public void saveData() 16 { 17 //do something else 18 //保存数据 19 db.saveDB(); 20 } 21 } 22 //现在修改为向XML文件保存 23 public class XMLData 24 { 25 //向xml中保存数据 26 public void saveXML() 27 { 28 } 29 } 30 //这个时候需要重新修改业务逻辑业务逻辑 31 public class Business 32 { 33 private XMLData xml = new XMLData(); 34 //数据保存 35 public void saveData() 36 { 37 //do something esle 38 //保存数据 39 xml.saveXML(); 40 } 41 }
可以看到 这种方法的不方便之处在于更改存储方式的时候,就需要更新全部的逻辑与方法
//定义一个接口 public interface SaveData() { public void saveData(); } //数据操作类 public class DataBase implements SaveData { //向数据库中存储数据,实现接口的存储接口 public void saveData() { //具体的向数据库中存入数据的逻辑 } } //业务逻辑类 public class Business { //定义数据接口 private SaveData db; //定义数据保存类,这里传入的参数实际上是接口的子类,用顶级接口接收 public void setSaveData(SaveData db) { //通过向上转型 this.db = db; } public void saveData() { //do something this.db.saveData(); } } //测试类 public class TestBusiness { private Business b = new Business(); public void saveData() { ..... b.setSaveData(new DataBase()); } }
现在的好处就是使Business成为一个工厂,调用者无需关心底部存储的细节,只需要将存储方法设定到business,然后调用保存即可,而且这样一来
扩展也变得容易了,首先编写xml存储方法(继承savedata接口,并且实现存储方法),然后business无需更改,在业务逻辑传递进去xml存储对象即可.
可以看到,这样实现使得代码得到重用,而且增强了扩展性.
依赖注入:原本的方式是业务逻辑控制具体的存储方式,但是面向接口了以后,就不再业务逻辑里面编写具体的存储方式了,而是在调用业务逻辑的类里控制具体的存储方式,也就是上面的,由testbusiness调用业务逻辑的时候,控制了存储方式(原本是业务逻辑设定好存储方式然后供调用),看起来是由具体的存储方式控制了业务逻辑.
注入方式:
1.set注入,也就是在business中定义一个私有的存储接口变量,然后定义set方法,注入具体的存储方式.
2.接口注入,具体存储方式与存储接口还是一样,但是在业务逻辑中定义的是业务逻辑接口,然后在这个接口中定义了需要注入的信息(比如定义一个Disavedata(SaveData db)),然后每个业务逻辑都需要去继承这个接口,然后实现这个存储方法,在原本的set方法上,相当于保证了每个业务逻辑都有一个默认的注入方法(可以覆写).
3,构造注入,跟set方法相比 只是把注入的逻辑放到了business的构造方法里面.
可以看到,无论是采用哪种方法,都需要使用面向接口编程
标签:style blog color io 使用 文件 数据 div sp
原文地址:http://www.cnblogs.com/color-my-life/p/3967419.html