设计模式-适配器.docVIP

设计模式之---适配器 适配器模式 先考虑这种设计模式适用场景： 假如我们有一个运行良好的接口以及其实现，（Version 1.0，比如说是按照用户要求开发的日志系统，这个日志系统是基于文件记录的FileLogger）， 但是由于系统升级或者用户需求变化等，我们又设计了一个新的接口以及实现（Version 2.0，比如说是按照用户的要求，让日志系统是基于数据库记录的DBLogger），并且这个新设计的接口也能良好运行... 假如到此为止，我们还没看出设计模式的用武之地。然而，我们知道，用户的需求创意是无穷无尽的，现在用户说了，我们想同时用这两种日志系统... 就是说，现如今的业务是运行在Version 2.0 的接口上，但是我要用 Version 1.0的实现... 好，需求出来了，那么怎么实现呢？两个接口的方法都不一致（兼容）？ 说起来也简单，大约有这么2套方案： 1，我们按照DBLogger的接口，在重新开发一套，适用于文件系统的日志。 2，直接修改Version 1.0 的代码。 先说第一种方案，这么做确实可以，而且很直观。但是在我们已完成相应功能的前提下，再重新写一套代码其实是没有必要的，并且代码复用性也不高。 从这个角度考虑，如果有更好的办法，我们可以将这个方案pass掉。 再说第二种方案，第二种方案也可以解决问题，但是它暴露的问题更加明显。如果直接修改第一版本的代码，那么很可能造成其他依赖这些代码的 代码不能运行，也就是存在依赖关系的约束。这个方案还不如第一个方案，所以我们毫不犹豫的把它pass！ 两种方案都被否定了，下面就是 适配器模式 上场了。 适配器模式作用：将一个接口转化为客户端希望的另一个接口，使得原本由于接口不相容的两个类，可以相互配合的一起工作。 主要就是起一个转换器的作用，目的就是复用原来的功能，说白了就是让两个接口匹配起来。想想看，适配器的作用在生活中很常见， 比如管道转接头，三相插座插口转换器等。 这就是 适配器模式 出现的背景... 下面我们看一下代码的实现： 首先看一下日志模型类（JavaBean）： package mode.adaptor; /** * 这是日志对象的模型 简化点写，只有操作人和操作 * * @author root * */ public class LogModel { private String uuid; private String operator;// 操作人 private String operate;// 操作 private String timestamp;// 操作时间 public String getUuid() { return uuid; } public void setUuid(String uuid) { this.uuid = uuid; } public String getOperator() { return operator; } public void setOperator(String operator) { this.operator = operator; } public String getOperate() { return operate; } public void setOperate(String operate) { this.operate = operate; } public String getTimestamp() { return timestamp; } public void setTimestamp(String timestamp) { this.timestamp = timestamp; } public String toString() { return 用户 + this.getOperator() + 在 + this.getTimestamp() + 做了 + this.getOperate() + 操作; } } 然后在看一下 Version 1.0的日志系统接口，面向文件的： package mode.adaptor; import java.util.List; /** * 文件日志系统的操作接口 * @author root * */ public interface FileLogger { public ListLogModel readLog(); public void writeLog(LogModel model); } 以及具体实现： package mode.adapto