增删改查也有设计模式——依赖倒置原则另解

一个增删改查的例子解读面向接口编程和依赖倒置原则

依赖倒置原则介绍

依赖倒置原则包括两个部分

  • .高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象。
  • 抽象不应该依赖于具体实现,具体实现应该依赖于抽象。

    例子

    现在有如下场景和需求:
    老板要求设计任务模块,包括发布任务和撤回任务等。

    假设这个需求只给了几个小时去做,那肯定是来不及设计了,写到哪算哪。
    定义撤回接口的控制层如下

@RequestMapping(‘cancel‘)
@ResponseBody
public String cancelTask(Task task){
  // TODO 调用service的撤回接口
  return "{‘status‘:‘success‘}";
}

重点来了

这个时候已经写到这个地方了,服务层的cancel接口还没写好,因为在SpringMVC数据自动绑定的时候有了一个task对象,自然而然会联想到定义如下接口

public void cancel(Task task) throws ServiceException{};
而不是
public void cancel(String taskId) throws ServiceException{}

因为我手头有一个现成的task对象,我首先想到的传递参数就是task。两种差异也很简单,第二个需要在代码里多一个

Task task = this.findOneById(taskId); //因为是在service层的代码,一般都有findOneById这个接口

好了,因为我已经有task,所以这个时候我会很自然的给我两种暗示:

  • 如果我接受的参数是taskId我需要在和数据库做IO,如果调用方已经IO过一次了那我这个动作不是多余的吗
  • 调用方应该可以保证传给我的task是正确的数据

这里已经出现了错误的依赖的问题了
1 在定义接口时我们假设传进来的参数是数据库中最新的,但是这个根本无法保证。撤销接口的职责是什么?是将任务的状态从处理中变为待处理
2 高层和底层都依赖了实现,因为这里是基于我已经有了task对象,不想再IO消耗性能这段已经存在的代码逻辑去定义接口的
正确的应该是
当定义撤回接口时应该抛开已有的代码,去想这个接口的职责:变更状态,做其他操作
1 变更状态只需要id即可,其他操作也不依赖于高层的传递参数
2 定义接口时应该考虑他的职责去定义抽象,而代码实现应该遵守这个抽象所要实现的功能

这个就是

  • .高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象。
  • 抽象不应该依赖于具体实现,具体实现应该依赖于抽象。
    同样也是

    面向接口编程

上面是自己开发过程中发现的另解,通解如下

依赖倒置原则实际讲的是高层调用低层时不应该通过实现类去调用,而是通过接口去调用,这样一旦低层出现了较大的变动,上层不会有太大波动。

假设如下场景

学生读书

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();
}

这样一旦小明要看其他的书,在参数传递时修改具体派生对象就可以了。
这个原则属于设计模式中比较常用的原则,很多设计模式都是定义一些派生类去实现接口。如抽象工厂类,定义一组接口,由具体工厂类去实现,当需要切换其他模式的时候,切换实现类即可。
策略模式:定义一个算法接口,要求他们可以随时切换,不同的算法派生类都实现同一个接口。算法调用类依赖于接口而不是具体策略类。

原文地址:http://blog.51cto.com/13985113/2309599

时间: 2024-10-13 10:39:18

增删改查也有设计模式——依赖倒置原则另解的相关文章

依赖倒置原则详解--七大面向对象设计原则(3)

依赖倒置原则来源: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 依赖倒置原则(Dependence Inversion Principle)是程序要依赖于抽象接口,不要依赖于具体实现.简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合. A.高层模块不应该依赖低层模块,二者都应该依赖其抽象.抽象

设计模式 - 依赖倒置原则

先看文章一:http://www.cnblogs.com/painsOnline/p/5138806.html(前半部分) 在看文章二:http://baike.baidu.com/link?url=BPC2OUFFHc7l14iLo70URxt8ae4-Wukbl3S077cCYpZljhFOHeK5prDuuMCyU7kwJwYvFnN1nKdevzsTrbJY7_(全部)

DAO设计模式实现数据库的增删改查(进一步封装JDBC工具类)

一.DAO模式简介 DAO即Data Access Object,数据访问接口.数据访问:故名思义就是与数据库打交道.夹在业务逻辑与数据库资源中间. DAO模式实际上是两个模式的组合,即Data Accessor (数据访问者)模式和 Active Domain Object(领域对象)模式.Data Accessor 模式实现了数据访问和业务逻辑的分离:Active Domain Object 模式实现了业务数据的对象化封装. 需要注意的是,DAO设计模式是Java EE中的设计模式,而非Ja

MySQL数据库学习笔记(十一)----DAO设计模式实现数据库的增删改查(进一步封装JDBC工具类)

[声明] 欢迎转载,但请保留文章原始出处→_→ 生命壹号:http://www.cnblogs.com/smyhvae/ 文章来源:http://www.cnblogs.com/smyhvae/p/4059514.html 联系方式:[email protected] [正文] 一.DAO模式简介 DAO即Data Access Object,数据访问接口.数据访问:故名思义就是与数据库打交道.夹在业务逻辑与数据库资源中间. DAO模式实际上是两个模式的组合,即Data Accessor (数据

MVC实例及用三层架构实现对学生信息的增删改查

一.MVC设计模式实例 M层 Login.java package org.entity; public class Login { private int id; private String uname; private String upwd; public Login() { } public Login( String uname, String upwd) { this.uname = uname; this.upwd = upwd; } public Login(int id, S

【Android】Sqlite数据库增删改查

Android系统内置一个Sqlite数据库,如果app需要使用Sqlite数据库数据库存储数据,Android会为此app生成一个.db文件.这个数据库在data/data/<package_name>/databases里面,其中<package_name>为该安卓app的工程包名,这个目录必须root后才能看到.在Windows,单机的应用程序,存储数据,基本放到一个文件里面,正如游戏的存档,基本就是把当前的游戏状态存到一个用户很难找到的文件里面.每次存档读档就是一个从这个存

[转]什么是Pro*C/C++,嵌入式SQL,第一个pro*c程序,pro*c++,Makefile,Proc增删改查

1 什么是Pro*C/C++ 1.通过在过程编程语言C/C++中嵌入SQL语句而开发出的应用程序 2.什么是嵌入式SQL 1.在通用编程语言中使用的SQL称为嵌入式SQL 2.在SQL标准中定义了很多中语言的嵌入式SQL 3.各个厂商对嵌入式SQL的具体实现不同 3.什么是Pro*C/C++ 1.在C/C++语言中嵌入SQL语句而开发出的应用程序. 2.目的:使c/c++这种效率语言称为访问数据库的工具. 4.嵌入式SQL的载体是宿主语言 宿主语言 Pro程序 C/C++ Pro*C/C++ F

开源工具DbUtils的使用(数据库的增删改查)

一.DbUtils简介: DBUtils是apache下的一个小巧的JDBC轻量级封装的工具包,其最核心的特性是结果集的封装,可以直接将查询出来的结果集封装成JavaBean,这就为我们做了最枯燥乏味.最容易出错的一大部分工作. 下载地址:http://commons.apache.org/proper/commons-dbutils/download_dbutils.cgi 下载上图中的红框部分,然后解压.解压之后的文件如下 : 上图中红框部分的文件就是我们所需要的内容. 二.核心方法: Db

EF5(6) 简单三层 增删改查

1:项目结构 2:每层添加对其他层的引用,这里我们把除了Web层之外的所有的层生成的文件都放到解决方案下的Library文件夹下,然后每个项目分别来引用里面的dll项目文件. 我们在Model项目上,右键属性->生成-> 在下面的输出里面,选择上一级的 Library文件夹 2.2 我们调整项目的生成顺序 ,在解决方案或者是任意项目上右键,选择 生成依赖项,调整各个项目的依赖,这样的目的就是调整项目的生成顺序. 注意,这里你选择依赖项,并没有给项目与项目之间增加了dll的引用,只是单纯的修改了