Design Principles and Design Patterns

Posted 2020-12-30 lightsong

设计原则解读。

设计原则是对设计模式的约束性要求，属于设计中基本的四项特征，不符合此四项特征的设计，不具有生命力。

设计模式也是在此四项设计原则上的具体化实例化衍生物。

 

Martin原文：

http://www.cvc.uab.es/shared/teach/a21291/temes/object_oriented_design/materials_adicionals/principles_and_patterns.pdf

 

Architecture and Dependencies

软件最开始的的设计，一般都是完美的，但是往往在软件后续的开发维护过程中，一点点的恶化掉，导致软件软件无法维护。

软件开发维护过程中，对软件的修改又是必不可少的，因为需求的变化是必可避免的，又是变化多样的， 对设计框架的冲击也最大。

后期维护者，由于项目需求的紧急程度，可能在不理解的原始设计的背景下，添加新的需求实现，违背了原始设计，则设计被破坏，后续维护者更加迷惘。

 

Symptoms of Rotting Design -- 设计恶化的特征

Rigidity - 修改困难

新的需求，不好在现有实现上添加代码实现。

Fragility - 脆弱性

新的修改， 牵扯到多个模块，且容易引入bug，导致一连串的修改，又继续扩散， 产品不再信任。

Immobility - 不可移植性

一个大项目，包括若干子功能， 功能见有复用的地方， 但是开发者却无法复用，因为依赖不清晰，拆分功能对原有功能产生影响。

Viscosity - 粘性

设计的粘性 和 环境的粘性

当保持设计的成本比较大， 则设计具有粘性，开发者往往会选择hack的方法，这种方法更加具有破坏性，设计的不好呗。

开发者开发的功能依赖开发环境，难于移植的生产环境，则产生环境的粘性。

 

Changing Requirements -- 变化的需求

不说了， 产品经理被打了，就说名需求的变化到底有多么剧烈。

 

Dependency Management -- 依赖管理

不恰当的模块依赖，加重的系统间的耦合， 导致源码更加难于管理。

合理的依赖防火墙，可以防止系统的设计的恶化。

 

 

Principles of Object Oriented Class Design

  The Open Closed Principle (OCP) -- 开闭法则

A module should be open for extension but closed for modification.

 

Dynamic Polymorphism -- 动态多态

定义抽象的接口，具体的类实现此方法。 高层的逻辑操作逻辑对接口对象进行编程，不对具体类编程。

Static Polymorphism -- 静态多态

编译阶段使用的模板，在编译完成后，静态绑定待操作对象。

 

 Architectural Goals of the OCP

开闭法则，要求设计者具有深刻的洞察力， 分辨出系统中那些部分是变化的，那些部分是不变的， 并将变化的内容，设置出扩展的机制。 例如虚拟接口，虚拟类，允许使用者实现或者替换接口，通过接口添加新的功能， 当然此功能早已经在设计之内，非设计之外的功能不能此类接口的职责之内，如果有则表明，现有设计并不全面。

 

The Liskov Substitution Principle (LSP)

Subclasses should be substitutable for their base classes

 子类可以随时被父类替换。

对于父亲类暴露出去的接口，其实现的功能，  子类应该无条件完全实现， 不多也不能少。

Design by Contract -- 基于契约的设计

理解为面向接口的设计，接口就是使用方 和 实现方的公约，不容变化。

 

  The Dependency Inversion Principle (DIP)

Depend upon Abstractions. Do not depend upon concretions.

 

一般实现，高层依赖中层，中层依赖底层：

每一层的直接依赖，不应该直接产生，应该给予抽象产生，即高层的底层都不应直接产生依赖，

已该生成出一个抽象层，类似接口契约， 高层依赖抽象层的接口，

底层实现抽象层的接口。

 

 

 

 

  The Interface Segregation Principle (ISP)

 Many client specific interfaces are better than one general purpose interface

 对于接口的设计，不要整一个大而全的接口， 因为每个接口都具有不同组织的属性， 更加细分接口更加有利于管理接口， 并实现接口。

统一实现一个接口，则任何接口的变动，都将引起所有使用接口客户端的变动。

 

生动解释见：

https://www.jianshu.com/p/184a90eb3349