增删改查也有设计模式——依赖倒置原则另解
一个增删改查的例子解读面向接口编程和依赖倒置原则
依赖倒置原则介绍依赖倒置原则包括两个部分
@RequestMapping(‘cancel‘) @ResponseBody public String cancelTask(Task task){ // TODO 调用service的撤回接口 return "{‘status‘:‘success‘}"; } 重点来了这个时候已经写到这个地方了,服务层的cancel接口还没写好,因为在SpringMVC数据自动绑定的时候有了一个task对象,自然而然会联想到定义如下接口
因为我手头有一个现成的task对象,我首先想到的传递参数就是task。两种差异也很简单,第二个需要在代码里多一个
好了,因为我已经有task,所以这个时候我会很自然的给我两种暗示:
这里已经出现了错误的依赖的问题了 这个就是
上面是自己开发过程中发现的另解,通解如下依赖倒置原则实际讲的是高层调用低层时不应该通过实现类去调用,而是通过接口去调用,这样一旦低层出现了较大的变动,上层不会有太大波动。 假设如下场景学生读书 public class Student{ public void read(Honglou honglou){ // 遍历每一行 for(Line line: honglou.getLines){ // 小明一行一行看 this.see(line); } } } public class Honglou{ public List<Line> getLines(){}; } 此时小明依赖于具体类Honglou,一旦小明想读其他书(使用其他实现)就无法实现了。 如果此时定义一个IBook类作为基类: public class Student{ public void read(IBook book){ // 遍历每一行 for(Line line: book.getLines){ // 小明一行一行看 this.see(line); } } } public interface IBook{ public List<Line> getLines(); } 这样一旦小明要看其他的书,在参数传递时修改具体派生对象就可以了。这个原则属于设计模式中比较常用的原则,很多设计模式都是定义一些派生类去实现接口。如抽象工厂类,定义一组接口,由具体工厂类去实现,当需要切换其他模式的时候,切换实现类即可。策略模式:定义一个算法接口,要求他们可以随时切换,不同的算法派生类都实现同一个接口。算法调用类依赖于接口而不是具体策略类。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |