初识设计模式软件设计的六大原则

Posted 2020-07-26 jamesK4W

总结：本篇文字分为两个部分。第一部分：设计模式基本常识；第二部分：软件设计中的六大原则，并详细分析了单一职责原则。（本篇文章的时间轴参考：为知笔记支撑文件夹\Java设计模式（时间序列图）.vsdx）

部分一：初识设计模式

什么是设计模式？James拿到这个论点时，很是迷惑！

模式？是不是一个模子？模式识别——计算机领域的经典问题？

设计模拟？软件的设计模式？不懂！！！

但是在实际编码、调试过程中，James的遇到过很是难解的问题：工程代码中有过多的冗余代码——代码复用性不高；需求一旦改变，需要更改很多地方的代码逻辑——代码灵活性不强……

那先看看设计模式的概念吧！

设计模式是一套被反复使用、为多数人知晓、经过分类编目的、代码设计经验的总结。为了编写可重用性代码，让代码更容易被他人理解，并保证代码可靠性而使用的设计思想。

设计模式使代码编制真正工程化。

设计模式是软件行业智慧积累的结晶；它提出了一系列标准术语，概括了相关行业中经验丰富的从业者所应用的所有概念和方法。

常用的23种设计模式如下：

1.单例模式；

2.工厂方法模式；　

3.抽象工厂模式；　

4.模版方法模式；　

5.建造者模式；　

6.代理模式；　

7.原型模式；　

8.中介者模式；　

9.命令模式；　

10.责任链模式；　

11.装饰模式；　

12.策略模式；　

13.适配器模式；　

14.迭代器模式；　

15.组合模式；　

16.观察者模式；　

17.门面模式；　

18.备忘录模式；

19.访问者模式；　

20.状态模式；　

21.解释器模式；　

22.享元模式；　

23.桥梁模式；

设计模式的起源是面向对象程序设计思想，是面向对象设计的精髓——抽象；面向对象通过类和对象来实现抽象，实现时产生了面向对象的三种重要机制：封装、继承和多态。而这三种机制衍生了各式各样的设计模式。

在运用面向对象思想进行软件设计时，需要遵循以下原则：

1. 单一责任原则；

2. 里氏替换原则；

3. 依赖倒置原则；

4. 接口隔离原则；

5. 迪米特法原则；

6. 开闭原则；

这23种设计模式按设计意图可组织成五类：接口型模式，责任型模式、构造型模式，操作型模式以及扩展型模式。模式的设计意图指出了应用一个模式的价值所在。但上面所说的23中的某种设计模式，并不是仅仅支持一种设计意图。

在软件设计过程中，只要我们尽量遵循以上设计原则，设计出来的软件一定是优秀的，且足够健壮、稳定，并有足够的灵活性来迎接需求的变更。

那James还是不知道为什么，比如：这些原则的含义是什么？它们为什么而出现，解决了什么工程问题？这些原则和之前讲述的23种设计模式有什么联系？如何在我们的工程代码中使用……

这些疑问都需要James一一解决，不过James相信自己肯定能够战胜这些困难。（纵使是住着握手楼、吃着方便面、挤着公交车，只要能够活下来，就有希望！别人能做出来的东西，自己为什么不行？要有必胜的信心！）

部分二：从设计原则开始——单一职责原则

单一职责原则：应该有且仅有一个原因引起类的变更。

为什么在这里出现的是类？是不是仅仅只应用于类的设计？

（为什么会出现这种设计原则？）当一个类承担了过多的职责，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者一直这个类完成其他职责的能力。问题就出在耦合性上！

软件设计真正要做的工作是：发现职责并把那些职责互相分离。单一职责可使类的复杂性降低，其实现的工作有明确且清晰的定义。

那问题来了，James不明白什么是“类的变更”？

（如何实践单一职责原则？）考虑到如何使用代码实现单一责任原则（代码即是思路嘛），好在有百度和谷歌。下面就使用网站上的例子讲解，James认为：用这个例子比较容易说明问题。

需求分析：烹饪，做一道鱼香茄子。

public interface Cooking {
    // 获取菜名
    String getCookingName();
    void setCookingName(String cookingName);
    
    // 烹饪之前的准备工作：摘菜、洗菜等等，准备相应的食材
    void doPrepare(String vegetableName);
    
    // 烹饪模式：蒸、煮、炒、炸等，并提供菜名
    void doFire(String cookingName, String mode);
}

如果James想要烹饪一道鱼香茄子，可以覆写以上四个方法，从获知菜名、准备食材到具体的烹饪操作。从信息和行为的角度来说，前面两个方法是鱼香茄子相关的信息，后两个则是相关的行为（烹饪具体的行为）。

如果考虑如下方式是否更完善？

public interface ICookingInfo {
    // 获取菜名
    String getCookingName();
    void setCookingName(String cookingName);
}

public interface ICookingFire {
    // 烹饪之前的准备工作：摘菜、洗菜等等，准备相应的食材
    void doPrepare(ICookingInfo info);

    // 烹饪模式：蒸、煮、炒、炸等，并提供菜名
    void doFire(ICookingInfo info, String mode);
}

Cooking类包含两个部分，一个部分的职责是获取菜名及相关信息（口味、特点…），另一个部分的职责是具体烹饪（当然需要菜名相关信息啦）。

如果ICookingInfo发生改变，势必会造成ICookingFire的改变。对于职责不同的两个部分，需要拆分。那在Cooking类中，只需要实现上述两个不同接口，即可实现烹饪一道菜的功能。

public class Cooking implements ICookingInfo, ICookingFire {
    @Override
    public String getCookingName() {
        return null;
    }

    @Override
    public void setCookingName(String cookingName) {

    }

    @Override
    public void doPrepare(ICookingInfo info) {

    }

    @Override
    public void doFire(ICookingInfo info, String mode) {

    }

}

产生了Cooking对象后，可将其视为ICookingInfo或者ICookingFire接口使用；如果需要设置菜名或其他信息，可以当做是ICookingInfo的实现类；要是进行烹饪操作，就当做是ICookingFire的实现类。（突然引出了一个问题：James貌似不太理解类和其实现的接口之间的关系……）

总之，在接口设计中，如果接口可细分为不同的“职责”，就可将该接口进一步细分。

上述仅仅只是从接口角度解读了：单一职责原则，此外还可以用在类的设计、方法的定义上。归结为一点：自己的事情自己做，并承担相应的责任。

可参考一下实例分析：

1. http://blog.csdn.net/zhengzhb/article/details/7278174 从类的角度解读；

2. 待续……

单一职责原则的优点：

1. 类的复杂性降低，实现什么职责都有清晰明确的定义；

2. 可读性提高；

3. 可维护性提高；

4. 变更引起的风险降低；如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，对系统的扩展性、维护性都有非常大的帮助

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

单一职责原则可以使用到哪些方面？单一职责原则适用于接口、类，同样适用于方法（一个方法尽可能只做一件事情）。接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

但凡事都有需要权衡利弊的地方，不能因为生搬硬套单一职责原则，而让系统变得繁杂而庞大。