设计模式之七大原则

详细内容请移步至语雀文档：点击跳转

软件开发过程中，要面临来自耦合性、内聚性、可维护性、可扩展性、重用性、灵活性等多方面的挑战，而设计模式则是为了解决以上问题，使代码具有更好的重用性、可读性、可扩展性、可靠性，并且使程序呈现高内聚，低耦合的特性。而设计模式的原则则就是程序员在开发时应该遵循的原则，也是设计模式的基础。

设计模式要遵循的原则主要有SOLID（单一职责、开闭原则、里氏替换、接口隔离以及依赖反转）这五个基本原则。除了这五个基本原则，还有两个常见的原则，他们分别是合成复用原则、最少知识原则（又称迪米特法则）。

一、单一职责原则

单一职责原则（single responsibility principle）： 对类来说，即一个类应该只负责一项职责。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。例如类 A 负责两个不同职责：职责 1，职责 2。当职责 1 需求变更而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2。单一职责原则可以降低类的复杂度，一个类只负责一项职责，提高类的可读性，可维护性，降低变更引起的风险。

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
 (1) 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
 (2) 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点：
 (1) 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
 (2) 提高类的可读性。复杂性降低，自然其可读性会提高。
 (3) 提高系统的可维护性。可读性提高，那自然更容易维护了。
 (4) 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

1.1 错误案例

public class Manage {

    public void student(String teacher){
        System.out.println(teacher+ "对学生进行生活上的管理" );
    }
}

public class Pattern {

    public static void main(String[] args) {
        Manage manage = new Manage();
        manage.studentManager("辅导员");
        manage.studentManager("专业老师");
    }
}

//输出结果
辅导员对学生进行生活上的管理
专业老师对学生进行生活上的管理

1.2 正确案例

public class LifeManage {

    public void studentManager(String teacher){
        System.out.println(teacher+ "对学生进行生活上的管理" );
    }
}

public class StudyManage {

    public void studentManager(String teacher){
        System.out.println(teacher+ "对学生进行学习上的管理" );
    }
}

public class Pattern {

    public static void main(String[] args) {
        LifeManage lifeManage = new LifeManage();
        lifeManage.studentManager("辅导员");

        StudyManage studyManage = new StudyManage();
        studyManage.studentManager("专业老师");
    }
}

//输出结果
辅导员对学生进行生活上的管理
专业老师对学生进行学习上的管理

二、开放封闭原则 (open closed principle)

开放封闭原则（open closed principle）： 在面向对象编程领域中，开闭原则规定“软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的”，这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的，在这种环境中，改变源代码需要代码审查，单元测试以及诸如此类的用以确保产品使用质量的过程。遵循这种原则的代码在扩展时并不发生改变，因此无需上述的过程。

 

1.1 错误案例

null

1.2 正确案例

null