设计模式之七大设计原则

设计模式

• 目的：为了让程序有更好的代码的重用性（相同功能代码不用多次编写）、可读性（编程的规范性）、可扩展性（增加新的功能时，非常的方便）、可靠性（当增加新功能后，对原有功能没有影响）、使程序呈现高内聚，低耦合。

单一职责原则

基本介绍

• 对类来说，即一个类只负责一项指责x

应用实例

• 交通工具运行方式举例
  • 方式1中run 方法，违法了单一职责原则，解决该办法，根据不同的方式，拆分不同的类出来。
  • 方式2中遵守了单一职责原则，但改动很大，将类分解了，修改过多。
  • 方式3中没有对类进行大改动，只是增加方法，在方法级别上遵守单一职责，在类这个级别上没有遵守单一职责原则。

单一职责原则的注意和细节

• 降低类的复杂度
• 降低变更带来的风险
• 提高类的可读性，可维护性
• 通常情况下，要遵守单一职责原则，如果逻辑很简单，可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

接口隔离原则

基本介绍

• 客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

应用实例

需求如下

按照需求编写接口及对应类

• 没有满足接口隔离原则，一个类对另一个类的依赖并不建立在最小的接口上

将原本的进行拆分

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ActonKFH-1603008619086)(C:\Users\lenovo\AppData\Roaming\Typora\typora-user-images\1597801719284.png)]

依赖倒转原则

基本介绍

• 高层模块不应该依赖底层模块，应该依赖其抽象
• 抽象不应该依赖细节，细节要依赖抽象
• 依赖倒转的中心思想是面向接口编程
• 设计理念：对应于细节的多变性，抽象的东西稳定的多
• 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作

实际案例

• 有一个person类接收消息的功能

传统发放实现

• 简单
• 如果获取的对象是微信、短信等，就需要新增类，同时person类也要增加相应的接收方法

应用依赖倒转原则实现

• 引入一个抽象的接口，表示接收者，这样person类和接口发生依赖。

依赖关系传递的三种方式和应用案例

通过接口实现依赖传递

interface IOpenAndClose{
    public void open(ITV tv);
}
interface ITV{
    public void play();
}
class OpenAndClose implements IOpenAndClose{
    @Override
    public void open(ITV tv) {
        tv.play();
    }
}

通过构造方法依赖传递

interface IOpenAndClose{
    public void open();
}
interface ITV{
    public void play();
}
class OpenAndClose implements IOpenAndClose{
    public ITV itv;
    public OpenAndClose(ITV itv){
        this.itv = itv;
    }
    public void open(){
        this.itv.play();
    }
}

通过setter方法传递

interface IopenAndClose{
    public void open();
    public void setTv(ITV itv);
}
interface ITV{
    public void play();
}

class OpenAndClose implements IopenAndClose{
    private ITV itv;

    @Override
    public void setTv(ITV itv) {
        this.itv = itv;
    }

    @Override
    public void open() {
        this.itv.play();
    }
}

注意事项和细节

• 底层模块尽量都要有抽象类或接口，程序稳定性更好
• 变量的声明类型尽量是抽象类或接口，变量引用和实际对象间就存在一个缓冲，有利于程序扩展和优化
• 继承时遵循里氏替换原则

里氏替换原则

基本介绍

• 如果对每一个类型位T1的对象o1，都有类型位T2的对象o2，即所有引用基类的地方必须能透明地使用其子类的对象
• 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法
• 继承实际上让两个类的耦合性增强，在适当情况下，可以通过聚合，组合，依赖来解决问题

实际案例

继承时无意修改了父类

按照里氏替换原则改写

• 让原有的父类和子类都继承一个更通俗的基本类，将原有的继承关系去掉，使用组合等方式替代

开闭原则

基本介绍

• 是编程中最基础、最重要的设计原则
• 一个软件实体如类，模块和函数应该对扩展开放【提供方】，对修改关闭【使用方】。用抽象构建框架，用实现扩展细节
• 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化
• 编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则

实际案例

• 完成一个画图形的功能
• 类图设计如下：

分析

• 好理解，简单
• 违反了设计模式的ocp原则
• 如果要多画三角形，要修改的地方较多

按照ocp原则修改

思路

• 把创建Shape类做成抽象类，并提供一个抽象的draw方法，让子类去实现就可

迪米特法则

基本介绍

• 一个对象应该对其它对象保持最少的了解
• 类与类关系越密切，耦合度越大
• 迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多复杂，都尽量将逻辑封装在类的内部
• 只与直接的朋友通信
  • 直接的朋友：每个对象都会与其它对象有耦合关系，有耦合关系就是朋友关系，出现成员变量、方法参数、方法返回值中的类为直接朋友，如果是出现在局部变量中的类不是直接的朋友。
  • 也就是说：陌生的类最好不要以局部变量的形式出现在类的内部

应用实例

• 有一个学校，有各个学院和总部，现要求打印出学校总部员工Id和各个学院员工的id

方案一

• SchoolManger类中的CollageEmployee是陌生的，以局部变量出现，违反了迪米特法则

方案二

• 改进：
  • 将CollageEmployee的输出拆分

注意事项和细节

• 降低类之间的耦合
• 只是降低耦合关系，不是完全没有依赖关系

合成复用原则

基本介绍

• 尽量使用合成、聚合的方式，而不是使用继承

类图展示

原则的核心思想

• 找出应用中可能需要变化之处，把它们独立出来，不要和那些部需要变化的代码混在一起
• 针对接口编程，而不是针对实现编程
• 为了交互对象之间的松耦合设计而努力

降低耦合关系，不是完全没有依赖关系

合成复用原则

基本介绍

• 尽量使用合成、聚合的方式，而不是使用继承

类图展示

[外链图片转存中…(img-MmfaKJTB-1603008619099)]

原则的核心思想

• 找出应用中可能需要变化之处，把它们独立出来，不要和那些部需要变化的代码混在一起
• 针对接口编程，而不是针对实现编程
• 为了交互对象之间的松耦合设计而努力