后端开发｜设计模式

type

status

date

slug

summary

专业术语

开闭原则 OCP Open Closed Principle

鲁棒性 Robustness

单一职责原则 SRP Single Responsibility Principle

接口隔离原则 ISP Interface Segregation Principle

依赖倒置原则 DIP Dependence Inversion Principle

里氏替换原则 LSP Liskov substitution principle

表现层状态转化 REST Representational State Transfer

前文引言

开发功能、开发软件、开发系统对于开发者来源，个人认为可读性、扩展性、鲁棒性是重要的。

可读性：铁打的营盘流水的兵，代码也有审美，避免屎上雕花。

扩展性：需求总是变化的，如何不修改原系统的前提下实现灵活扩展。

鲁棒性：未知或扰动总会发生，如何在该情况下仍可正常运行。

设计原则、设计模式是前辈在行业总结出来的通用经验。多体会、多理会。熟练掌握并不容易，形成自己的理解。

设计原则SOLID

开闭原则OCP

Software entities like classes, modules and functions should be open for extension but closed for modifications。

🤔 对修改关闭，对扩展开放！新增一个功能，如何在不修改原系统前提下实现，品品！不容易滴！

开发套路需要调整，面对抽象编程，而不面对具体编程。抽象相对稳定！类依赖于固定的抽象（修改关闭），但利用面向对象的继承和多态机制，通过覆盖方法来改变逻辑（扩展开放）。这是实施开闭原则的基本思路。

因此（抽象类约束）：

抽象接口或抽象类尽量稳定，一旦确定不允许修改。

参数类型，引用对象尽量使用接口或抽象类。

案例一: 画形状需求: 有圆形, 有椭圆形, 根据要求画出相应的形状

糟糕的设计

🤔 增加三角形该如何？

很明显，该实现方式需对原系统修改。

关键点：抽象出”Draw()”方法

优雅的设计

优点：

开闭原则保证现有代码的单元测试、集成测试不受影响，只需要对扩展的代码进行测试。

开闭原则提高代码复用性

单一职责原则SRP

A class should have only one reason to change.

单一类(模块)单一职责，提高内聚，降低耦合。若单一类(模块)多个职责，面临某职责变化抑制其他职责的风险，这种设计是脆弱的。

难点：如何判定职责足够单一？🤔 经验？

案例一: 做家务需求: 张三扫地李四买菜、做饭

新增“家务”导致具体实现都要调整

如何只做想做的呢？

接口隔离原则ISP

Clients should not be forced to depend upon interfaces that they don't use.
The dependency of one class to another one should depend on the smallest possible interface.

客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上。

要点：避免“胖接口”(Fat Interface)

依赖倒置原则DIP

在传统的应用架构中，低层次的组件设计用于被高层次的组件使用，这一点提供了逐步的构建一个复杂系统的可能。在这种结构下，高层次的组件直接依赖于低层次的组件去实现一些任务。这种对于低层次组件的依赖限制了高层次组件被重用的可行性。

依赖反转原则的目的是把高层次组件从对低层次组件的依赖中解耦出来，这样使得重用不同层级的组件实现变得可能。

倒置规则：

高层次的模块不应该依赖于低层次的模块，两者都应该依赖于抽象接口。

抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。

里氏替换原则LSP

If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program。

Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it。

如果S是T的子类，则T的对象可以替换为S的对象，而不会破坏程序。

所有引用其父类对象方法的地方，都可以透明的替换为其子类对象。

要点：遵守父类与子类的约定，包括输入、输出、异常、功能约定。（OCP的补充）(多态能力的约束）

前置条件不能被加强（输入）

后置条件不能被削弱（输出）

不能违背对异常的约定（异常）

不能违背方法功能的定义（功能）

UML类图（通用标准）

关系说明：参考
车的类图结构为<<abstract>>，表示车是一个抽象类；
它有两个继承类：小汽车和自行车；它们之间的关系为实现关系，使用带空心箭头的虚线表示；
小汽车为与SUV之间也是继承关系，它们之间的关系为泛化关系，使用带空心箭头的实线表示；
小汽车与发动机之间是组合关系，使用带实心箭头的实线表示；
学生与班级之间是聚合关系，使用带空心箭头的实线表示；
学生与身份证之间为关联关系，使用一根实线表示；
学生上学需要用到自行车，与自行车是一种依赖关系，使用带箭头的虚线表示；