设计模式的六大原则实例

一 设计模式的六大原则一 设计模式的六大原则 1 1 开闭原则 开闭原则 OpenOpen CloseClose PrinciplePrinciple 开闭原则就是说对扩展开放 对修改关闭对扩展开放 对修改关闭 在程序需要进行拓展的时候 不能 去修改原有的代码 实现一个热插拔的效果 所以一句话概括就是 为了使程 序的扩展性好 易于维护和升级 想要达到这样的效果 我们需要使用接口和 抽象类 开闭原则是面向对象的可复用设计的第一块基石 开闭原则是面向对象的可复用设计的第一块基石 开闭原则的关键是抽象化 开闭原则的关键是抽象化 2 2 里氏代换原则 里氏代换原则 LiskovLiskov SubstitutionSubstitution PrinciplePrinciple 里氏代换原则 Liskov Substitution Principle LSP 面向对象设计的基本 原则之一 里氏代换原则中说 任何基类可以出现的地方 子类一定可以出现 LSP 是继承复用的基石 只有当衍生类可以替换掉基类 软件单位的功能不受 到影响时 基类才能真正被复用 而衍生类也能够在基类的基础上增加新的行 为 里氏代换原则是对 开 闭 原则的补充 实现现 开开 闭闭 原则的关键步骤原则的关键步骤 就是抽象化 而基类与子类的继承关系就是抽象化的具体实现 所以里氏代换就是抽象化 而基类与子类的继承关系就是抽象化的具体实现 所以里氏代换 原则是对实现抽象化的具体步骤的规范 原则是对实现抽象化的具体步骤的规范 面向对象的设计关注的是对象的行为 它是使用 行为 来对对象进行分 类的 只有行为一致的对象才能抽象出一个类来 我经常说类的继承关系就是 一种 Is A 关系 实际上指的是行为上的 Is AIs A 关系 可以把它描述为 Act AsAct As 3 3 依赖倒转原则 依赖倒转原则 DependenceDependence InversionInversion PrinciplePrinciple 这个是开闭原则的基础 具体内容 真对接口编程真对接口编程 依赖于抽象而不依赖依赖于抽象而不依赖 于具体 于具体 4 4 接口隔离原则 接口隔离原则 InterfaceInterface SegregationSegregation PrinciplePrinciple 这个原则的意思是 使用多个隔离的接口 比使用单个接口要好 还是一个降 低类之间的耦合度的意思 从这儿我们看出 其实设计模式就是一个软件的设 计思想 从大型软件架构出发 为了升级和维护方便 所以上文中多次出现 降低依赖 降低耦合 5 5 迪米特法则 最少知道原则 迪米特法则 最少知道原则 DemeterDemeter PrinciplePrinciple 最少知道原则 就是说 一个实体应当尽量少的与其他实体之间发生相互作 用 使得系统功能模块相对独立 6 6 合成复用原则 合成复用原则 CompositeComposite ReuseReuse PrinciplePrinciple 合成 聚合复用原则是在一个新的对象里面使用一些已有的对象 使之成为新对在一个新的对象里面使用一些已有的对象 使之成为新对 象的一部分 新的对象通过向这些对象的委派达到复用已有功能的目的象的一部分 新的对象通过向这些对象的委派达到复用已有功能的目的 合成 Composition 和聚合 Aggregation 都是关联 Association 的特殊种类 原则是尽量使用合成 聚合的方式 而不是使用继承 11 开闭原则实例开闭原则实例 Fruit 接口 抽象产品 Orange 类 实现 fruit 接口 具体产品 Apple 类 实现 Fruit 接口 具体产品 Gardener 接口 抽象工厂 AppleGardener 类 实现 Gardener 接口 具体工厂 分管 apple 生产 OrangeGardener 类 实现 Gardener 接口 具体工厂 分管 orange 生产 package com zky www factory public interface Fruit 水果接口 public void plant public void grow public void harvest public class Apple implements Fruit 苹果实现水果接口 public void grow System out println apple is growing public void harvest System out println apple is harvesting public void plant System out println apple is planting public class Orange implements Fruit 桔子实现水果接口 public void grow System out println orange is growing public void harvest System out println orange is harvesting public void plant System out println orange is planting public interface Gardener 园丁接口 public Fruit getFruit public class AppleGardener implements Gardener Override public Fruit getFruit return new Apple public class OrangeGradener implements Gardener Override public Fruit getFruit return new Orange public class Client public static void main String args Gardener g1 new AppleGardener Apple apple Apple g1 getFruit apple harvest 22 里氏代换原则实例 里氏代换原则实例 正方形不是长方形正方形不是长方形 package com zky www liskov public class Rectangle private double width private double height public Rectangle public Rectangle double width double height super this width width this height height public double getWidth return width public void setWidth double width this width width public double getHeight return height public void setHeight double height this height height package com zky www liskov public class Square extends Rectangle private double side public Square double side super this side side public double getSide return side public void setSide double side this side side package com zky www liskov public class SmartTest public void resize Rectangle r while r getHeight r getWidth r setWidth r getWidth 1 33 依赖倒转原则实例 依赖倒转原则实例 public class Benz 汽车肯定会跑 public void run System out println 奔驰汽车开始运行 public class Driver 司机的主要职责就是驾驶汽车 public void drive Benz benz benz run public class Client public static void main String args Driver zhangSan new Driver Benz benz new Benz 张三开奔驰车 zhangSan drive benz 上面实例 司机张三只能开奔驰车 不能开其他车 因此设计出了问题 改正 如下 public interface IDriver 是司机就应该会驾驶汽车 public void drive ICar car public class Driver implements IDriver 司机的主要职责就是驾驶汽车 public void drive ICar car car run public interface ICar 是汽车就应该能跑 public void run public class Benz implements ICar 汽车肯定会跑 public void run System out println 奔驰汽车开始运行 public class BMW implements ICar 宝马车当然也可以开动了 public void run System out println 宝马汽车开始运行 在业务场景中 我们贯彻 抽象不应该依赖细节抽象不应该依赖细节 也就是我们认为抽象 ICar 接口 不依赖 BMW 和 Benz 两个实现类 细节 因此我们在高层次的 模块中应用都是抽象 Client 的实现过程如下 public class Client public static void main String args IDriver zhangSan new Driver ICar benz new Benz 张三开奔驰车 zhangSan drive benz Client 属于高层业务逻辑 它对低层模块的依赖都建立在抽象依赖都建立在抽象上 zhangSan 的显示类型显示类型是 IDriver benz 的显示类型显示类型是 ICar 也许你要问 在这 个高层模块中也调用到了低层模块 比如 new Driver 和 new Benz 等 如何 解释 确实如此 zhangSan 的显示类型是 IDriver 是一个接口 是抽象的 非实体化的 在其后的所有操作中 zhangSan 都是以 IDriver 类型进行操作 屏蔽了细节对抽象的影响 当然 张三如果要开宝马车 也很容易 我们只要 修改业务场景类就可以 注意在 Java 中 只要定义变量就必然要有类型 一个变量可以有两个类型 显示类型和真实类型 显示类型是在定义的时候赋予的类型 真实类型是对象 的类型 如 zhangSan 的显示类型是 IDriver 真实类型是 Driver 44 接口隔离原则接口隔离原则 public interface IPettyGirl 要有姣好的面孔 public void goodLooking 要有好身材 public void niceFigure 要有气质 public void greatTemperament public class PettyGirl implements IPettyGirl private String name 美女都有名字 public PettyGirl String name this name name 脸蛋漂亮 public void goodLooking System out println this name 脸蛋很漂亮 气质要好 public void greatTemperament System out println this name 气质非常好 身材要好 public void niceFigure System out println this name 身材非常棒 public abstract class AbstractSearcher protected IPettyGirl pettyGirl public AbstractSearcher IPettyGirl pettyGirl this pettyGirl pettyGirl 搜索美女 列出美女信息 public abstract void show public class Searcher extends AbstractSearcher public Searcher IPettyGirl pettyGirl super pettyGirl 展示美女的信息 public void show System out println 美女的信息如下 展示面容 super pettyGirl goodLooking 展示身材 super pettyGirl niceFigure 展示气质 super pettyGirl greatTemperament public class Client 搜索并展示美女信息 public static void main String args 定义一个美女 IPettyGirl yanYan new PettyGirl 嫣嫣 AbstractSearcher searcher new Searcher yanYan searcher show 如果星探想找有内在气质的 不找外形漂亮的 怎么办 看来 IPettyGirl 接口 功能有些臃肿 因此把原 IPettyGirl 接口拆分为两个接口 一种是外形美的 美女 IGoodBodyGirl 这类美女的特点就是脸 蛋和身材极棒 超一流 但是没 有审美素质 比如随地吐痰 出口就是脏话 文化程度比较低 另外一种是气 质美的美女 IGreatTemperamentGirl 谈吐和修养都非常高 我们从一个比较 臃肿的接口拆分 成了两个专门的接口 灵活性提高了 可维护性也增加了 不 管以后是要外形美的美女还是气质美的美女 都可以轻松的通过 PettyGirl 定 义 我们先看两种类型的美女接口 public interface IGoodBodyGirl 要有姣好的面孔 public void goodLooking 要有好身材 public void niceFigure public interface IGreatTemperamentGirl 要有气质 public void greatTemperament 实现类没有改变 只是实现类两个接口 源码如下 public class PettyGirl implements IGoodBodyGirl IGreatTemperamentGirl private String name 美女都有名字 public PettyGirl String name this name name 脸蛋漂亮 public void goodLooking System out println this name 脸蛋很漂亮 气质要好 public void greatTemperament System out println this name 气质非常好 身材要好 public void niceFigure System out println this name 身材非常棒 通过这样的改造以后 不管以后是要气质美女还是要外形美女 都可以保 持接口的稳定 当然你可能 要说了 以后可能审美观点再发生改变 只有脸蛋 好看就是美女 那这个 IGoodBody 接口还是要修改的呀 确实是 但是设计 时有限度的 不能无限的考虑未来的变更情况 否则就会陷入设计的泥潭中而 不能自拔 以上把一个臃肿的接口变更为两个独立的接口依赖的原则就是接口 隔离原则 让 AbstractSearcher 依 赖两个专用的接口比依赖一个综合的接口 要灵活 接口是我们设计时对外提供的契约 通过分散定义多个 接口 可以预 防未来变更的扩散 提高系统的灵活性和可维护性 55 迪米特法则迪米特法则 如果两个类不必彼此直接通信 那么这两个类就不应当发生直接的相互作用 如果其中的一个类需要调用另外一个类的某一个方法 可以通过第三者转发这 个调用 参考下例 Someone Friend 和 Stranger 三个类 public class Someone public void operation1 Friend friend Stranger stranger friend provide stranger operation3 所以 Someone 和 Friend 是朋友类 直接通讯的类 同理 Friend 类持有一个 Stranger 类的私有对象 他们是朋友类 public class Friend private Stranger stranger new Stranger public void operation2 public Stranger provide return stranger 在这里 Someone 类和 Stranger 类不是朋友类 但 Someone 类却通过 Friend 类知道了 Stranger 类的存在 这显然违反迪米特法则 现在 我们对 Someone 和 Friend 类进行重构 首先在 Friend 类里添加一 个方法 封装对 Stranger 类的操作 public class Friend private Stranger stranger new Stranger public void operation2 public Stranger provide return stranger public void forward stranger operation3 然后 我们重构 Someone 的 operation1 方法 让其调用新提供的 forward 方法 public class Someone public void operation1 Friend friend friend forward 现在 Someone 对 Stranger 的依赖完全通过 Friend 隔离 这样的结构已经 符合狭义迪米特法则了 仔细观察上述结构 会发现狭义迪米特法则一个明显的缺点 会在系统里 造出大量的小方法 散落在系统的各个角落 这些方法仅仅是传递间接的调用 因此与系统的商务逻辑无关 当设计师试图从一张类图看出总体的框架时 这 些小的方法会造成迷惑和困扰 遵循迪米特法则会使一个系统的局部设计简化 因为每一个局部都不会和远距离的对象有直接关联 但是 这也会造成系统的 不同模块之间的通信效率降低 也会使系统的不同模块之间不容易协调 结合依赖倒转原则 我们对代码进行如下重构来解决这个问题 首先添加一个 抽象的 Stranger 类 使 Someone 依赖于抽象的 Stranger 角色 而不是具体 实现 public abstract class AbstractStranger abstract void operation3 然后 让 Stranger 从该类继承 public class Stranger extends AbstractStranger public void operation3 随后 我们重构 Someone 使其依赖抽象的 Stranger 角色 public class Someone public void operation1 Friend friend AbstractStranger stranger friend provide stranger operation3 最后 我们重构 Friend 的 provide 方法 使其返回抽象角色 public class Friend private Stranger stranger new Stranger public void operation2 public AbstractStranger provide return stranger 现在 AbstractStranger 成为 Someone 的朋友类 而 Friend 类可以随时 替换掉 AbstractStranger 的实现类 Someone 不再需要了解 Stranger 的内部 实现细节 下图是重构后的 UML 类图 在将迪米特法则运用到系统的设计中时 应注意的几点 在类的划分上 应该创建有弱耦合的类 在类的结构设计上 每一个类都应当尽量降低成员的访问权限 在类的设计上 只要有可能 一个类应当设计成不变类 在对其他类的引用上 一个对象对其它对象的引用应当降到最低 尽量降低类的访问权限 谨慎使用序列化功能 不要暴露类成员 而应该提供相应的访问器 属性 66 合成复用原则实例 合成复用原则实例 1 1 聚合用来表示 聚合用来表示 拥有拥有 关系或者整体与部分的关系关系或者整体与部分的关系 代表部分的 对象有可能会被多个代表整体的对象所共享 而且不一定会随着某个代表 整体的对象被销毁或破坏而被销毁或破坏 部分的生命周期可以超越整体 例如 班级和学生 当班级删除后 学生还能存在 学生可以被培训机构 引用 class Student private String sName class Classes private Student student public Classes Student student this student student 2 2 合成用来表示一种强得多的 合成用来表示一种强得多的 拥有拥有 关系 关系 在一个合成关系里 部分和整 体的生命周期是一样的 一个合成的新对象完全拥有对其组成部分的支配权 包括它们的创建和湮灭等 使用程序语言的术语来说 合成而成的新对象对组 成部分的内存分配 内存释放有绝对的责任 一个合成关系中的成分对象是不能与另一个合成关系共享的 一个成分对象在 同一个时间内只