设计模式六大原则你都知道吗？

定义：

又称单一功能原则，其规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。

理解：

① 单一职责原则的核心是功能单一化，功能单一化后每个模块只受该功能的影响，不会出现其他功能的改变导致必须修改该模块。比方说登录模块和用户管理模块，如果合在一起，会导致如果需要增加一个临时登录的功能必然会影响用户管理模块，至少上线的时候用户管理模块也是断掉的。

② 实际上单一职责原则最重要的还是对事物的抽象化，比方说将画布抽象成一个整体，和将画布抽象成一个框架，里面的线的控制、锚点的自动增长等等功能抽象为一个个组件，这两种抽象方法明显是后面的更加细腻，也更加符合单一职责原则。单一职责原则要求你在抽象过程中尽可能的将事物抽象到无法再（或不需要再）抽象为止。

定义：

派生类（子类）对象可以在程式中代替其基类（超类）对象。

为什么要引入里氏替换原则：

① 总言：里氏替换原则是为了规范继承而产生的。父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。

② 继承的问题：

1) 继承作为面向对象的三大特征，有巨大的好处，但同时如果运用不当也会引起很多问题甚至bug。

2) 在开闭原则中，我们讲过要面向抽象编程，因为抽象不太会变化，而实现很容易由于需求的变更而发生变化。所以在编程过程中经常面临着在一段逻辑中，定义了其抽象，然后实现由于需求的变化导致变化的情况，此时如果子类胡乱重写父类的非抽象方法，这就会导致变更子类实现后直接导致逻辑发生问题。比方说 parent.method() 的功能是 +1；那所有子类的 method() 都应该是 +1，我在使用的时候也是按 +1 这个逻辑去处理的，但是由于乱写，导致其中一个子类的 method() 的功能却是 -1，那当这个实现切换到该子类的时候就会发生逻辑上的问题

3) 当然，上述的例子并不是说不遵守里氏替换原则就一定会出问题，万一原本的逻辑就是想让它 -1 呢，但是这样会导致bug出现的概率增高，因为它会导致继承体系的复用性较差。

定义：

高层模块（调用方）不应该依赖低层模块（被调用方），二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

理解：

① 依赖倒置原则是实现开闭原则的重要途径之一，本质上就是面向抽象（接口）编程，不要面向实现编程。

定义：

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

理解：

① 这个原则是用于对接口进行限制，让接口尽可能的单一、细化，防止接口变得臃肿，使得接口高内聚低耦合，从而使得类具有很好的可续性，可扩展性和可维护性。

② 接口细小化必须有一定限度，如果过于细化的话会导致接口过多，设计复杂化、碎片化，让整个系统变得非常复杂，所以要适度。

③ 举例：

▲ 图1：未遵循接口隔离原则的设计

这个图的意思是：类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。

可以看到，如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口，拆分后的设计如图2所示：

▲ 图2 遵循接口隔离原则的设计

定义：

一个对象应该对其他对象保持最少的了解，所以该原则也被称为最少知道原则，它只与直接的朋友通信。

理解：

① 迪米特法则可以尽量避免模块之间不必要的交互，达到低耦合，高内聚的目的。

定义：

软件对象（类、模块、方法等）应该对于扩展是开放的，对修改是关闭的。

理解：

① 在软件的生命周期中，由于修改变更或其他原因对软件进行修改是非常常见的。此时如果需要修改原代码则可能导致代码重构甚至引入bug；所以如果能不修改原代码，而是通过扩展软件来完成就好了。

② 实现开闭原则的核心是面向抽象编程，因为实现是容易变的，但抽象相对稳定。

③ 让类依赖于固定的抽象，所以对修改是封闭的；而通过面向对象的继承和多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。这是实施开放封闭原则的基本思路。

④ 开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

由我司自主开发的ModelCoder是一款支持多种嵌入式系统建模并可以自动生成高安全可靠的C代码的软件设计和开发工具。ModelCoder支持同步数据流以及状态机等嵌入式模型，其从模型生成代码的过程经过了形式化验证，以保证生成过程的正确无误性，能够用于飞行控制系统，航空电子系统，核电的DCS等多个安全关键领域的嵌入式软件的设计和开发。对标产品有国外ANSYS公司的SCADE或者MathWorks公司的MATLAB/Simulink。

ModelCoder软件是基于模型的设计工具，可以建模、仿真和分析动态系统。它能帮工程师提出一个关于系统的问题，建立这个系统的模型，然后看到仿真的结果。

使用ModelCoder软件，可以很容易从头开始建立一个模型，或者是修改存在的模型来满足设计要求。ModelCoder软件支持线性和非线性系统，也支持两者的混合系统。