代码的易复用、易扩展、易维护是代码组织的更高目标。
1 应对复杂性：抽象（abstract）、分解（decompose）
问题的数据抽象与功能（function）抽象，抽象出模块及模块分解。
从模块四要素去理解模块：
① 接口：模块的输入输出，隐藏实现，暴露接口；
② 功能：模块实现需要的功能；
③ 逻辑：功能如何实现及需要的数据；
④ 状态：模块的调用与被调用关系；
一个系统可以划分为不同的子系统，一个模块可以划分为更小的模块。
模块可以是函数(功能、 、接口)、类、由函数、类组成的模块、模块的模块、子系统、系统。
尽量实现模块的可复用性。
计算机系统就是一个分层抽象的系统。其中的编程语言也有不同的抽象层次，其中的C语言相对Java来说，抽象层次较低。
2 应对需求变化（功能增改），易于维护和扩展
2.1 功能增加时，不需要修改现有代码；
2.2 功能修改时，不影响其它代码；
要实现这两个目标，要求模块的高内聚、低耦合，模块满足七大设计原则。
也就是要避免"城门失火，殃及池鱼"，避免“牵一发而动全身”。
① 内聚：模块内部元素的相似程度；
② 耦合：本模块对其它模块的依赖程度。
3 模块耦合关系
分解操作形成模块，模块结合会形成模块依赖关系，也就是模块耦合关系。
编程中的各类关系所形成的依赖无处不在：
类的6类关系：
相对于继承（Inheritance），组合（Composition）具有较低的耦合关系，聚合（Aggregation）及其它关系的耦合性更低：
4 设计原则与设计模式
设计模式是以设计原则为基础。设计模式重点在于管理变化，提高复用，如果变化没有显现，模块没有利用价值时，就没有必要使用设计模式。Framework相对于Application，具有使用设计模式的更多场景。
设计原则以高内聚、低耦合为目标。
设计模式在什么地方应用：寻找变化点，在变化点应用模式。（将变化隔离，封装（C++封装为virtual函数），使得变化发生时，其它部分不受影响。）
Template Method定义一个操作中的算法的骨架（稳定），而将一些步骤延迟（变化）到子类中。Template Method使得子类可以不改变（复用）一个算法的结构（接口）即可重定义（override重写）该算法的某些特定步骤（如使用一个框架（以虚函数做为扩展点）时只需要重写某些虚函数即可）。
设计模式在什么时间应用：一般没有一步到位的设计模式，而是重构到模式，如常见的重构技法：
静态绑定→动态绑定（→表示转变为，下同）
编译时依赖→运行时依赖
早绑定→晚绑定（如虚函数和函数指针）
继承→组合
紧耦合→松耦合
5 七大设计原则 — SOLID & LC
这七大设计原则是业界在面向对象设计中经过总结精炼得出，在英文表示下各个原则首字母缩写就是 SOLID。
Single Responsibility Principle：单一职责原则Open Closed Principle：开闭原则Liskov Substitution Principle：里氏替换原则Interface Segregation Principle：接口隔离原则Dependence Inversion Principle：依赖倒置原则另外还有两个设计原则。
Law of Demeter：迪米特法则Composite/Aggregate Reuse Principle：组合/聚合复用原则5.1 单一职责原则(Single Responsibility Principle)
一个类只做一件事（一个类应该仅有一个引起它变化的原因，变化的方向隐含着类的责任。）。
业务对象（BO business object）、业务逻辑（BL business logic）拆解到单一职责的模块。
5.2 开放封闭原则（Open closed principle）
对外扩展开放，对内修改封闭。
扩展某类的功能时应该通过添加新的代码来实现而不是修改其内部的代码。
用抽象构建架构，用实现确保扩展。
5.3 里氏替换原则（LSP liskov substitution principle）
子类可以扩展父类的功能，但不能改变原有父类的功能。
子类必须能够替换它们的基类（is-a)。
继承表达类型抽象。
实际项目中，每个子类对应不同的业务含义，使父类作为参数，传递不同的子类完成不同的业务逻辑。如实现多态。
5.4 接口隔离（Interface segregation principle）
建立单一接口（扩展为类也是一种接口，一切皆接口）。
不应该强迫客户程序依赖它们不用的 （客户端不应该依赖它不需要的接口）。
该暴露的暴露（访问属性设置为public），该隐藏的隐藏（访问属性设置为private，类内部使用）。
接口应该小而完备。
一个类对另一个类的依赖应该建立在最小的接口上。
避免大接口被许多子类实现，造成耦合。降低了耦合，代码也变得好维护。
接口的设计粒度越小，系统越灵活，但是灵活的同时结构复杂性提高，开发难度也会变大，维护性降低。
5.5 依赖倒置原则（Dependence inversion principle）
高层模块（稳定）不应该依赖于低层模块（变化），二者都应该依赖于抽象（稳定）。
抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定），实现抽象时便会相互独立，这样就降低了模块的耦合度。
面向接口编程（通过接口作为参数实现应用场景）。
抽象就是接口或者抽象类，细节就是实现类（隐藏）。
也就是上面说的“隔离或封装变化”。
5.6 迪米特原则（Law of demeter LOD）
最少知道原则（Least Knowledge Principle 简写 LKP），尽量降低类与类之间的耦合；
一个对象应该对其他对象有最少的了解。如果对象 A 知道对象 B 的所有细节，那么对象 A 就可能会去使用到这些细节。如果你修改了其中对象 B 中的细节，就会不经意影响到 A。
5.7 组合/聚合复用原则（Composite/Aggregate Reuse Principle）
优先使用对象组合，而不是类继承。
类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。
继承属于一种硬编码。如果没有遵守里氏替换原则，父类一旦修改，所有子类都需要进行改变。
继承在某种程序上破坏了封装性，子类父类耦合度高。而对象组合则只要求组合的对象具有良好定义的接口。
以上七大设计原则的扩展：
5.8 封装变化点
使用封装来创建对象之间的分界层，让设计者可以在分界一侧进行修改，而不会对另一侧产生不良的影响，从而实现分界层之间的松耦合。
5.9 针对接口编程，而不是针对实现编程
不将变量类型声明为某个特定的具体类，而是声明为某个接口。
客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案。
6 23个设计模式的分类
根据设计模式的参考书 《Design Patterns - Elements of Reusable Object-Oriented Software》（《设计模式 - 可复用的面向对象软件元素》）中所提到的，总共有 23 种设计模式。这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。
另一种细分的标识：① 对象创建；② 对象性能；③ 单一职责；④ 组件协作；⑤ 接口隔离；⑥ 状态变化；⑦ 数据结构；⑧ 行为变化； ⑨ 领域问题
6.1 创建型模式（Creational Patterns）
这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
创建型模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成。就像我们去商场购买商品时，不需要知道商品是怎么生产出来的一样，因为它们由专门的厂商生产。
(1) 简单工厂模式（Factory Pattern）①
(2) 工厂方式模式（Factory Pattern）①
(3) 抽象工厂模式（Abstract Factory Pattern）①
(4) 单例模式（Singleton Pattern）[② 对象性能]
(5) 建造者模式（Builder Pattern）①
(6) 原型模式（Prototype Pattern）①
6.2 结构型模式（Structural Patterns）
这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。
结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。
由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。
(7) 适配器模式（Adapter Pattern）[⑤ 接口隔离]
(8) 桥接模式（Bridge Pattern）[③ 单一职责]
过滤器模式（Filter、Criteria Pattern）
(9) 组合模式（Composite Pattern）[⑦ 数据结构]
(10) 装饰器模式（Decorator Pattern）[③ 单一职责]
(11) 外观模式（Facade Pattern）[⑤ 接口隔离]
(12) 享元模式（Flyweight Pattern）[② 对象性能]
(13 模式（Proxy Pattern）[⑤ 接口隔离]
6.3 行为型模式（Behavioral Patterns）
这些设计模式特别关注对象之间的通信。
行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。
行为型模式分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象行为模式比类行为模式具有更大的灵活性。
(14) 责任链模式（Chain of Responsibility Pattern）[⑦ 数据结构]
(15) 命令模式（Command Pattern）[⑧ 行为变化]
(16) 解释器模式（Interpreter Pattern）[⑨ 领域问题]
(17 迭代器模式（Iterator Pattern）[⑦ 数据结构]
(18) 中介者模式（Mediator Pattern）[⑤ 接口隔离]
(19) 备忘录模式（Memento Pattern）[⑥ 状态变化]
(20) 观察者模式（Observer Pattern）[④ 组件协作]
(21) 状态模式（State Pattern）[⑥ 状态变化]
空对象模式（Null Object Pattern）
(22) 策略模式（Strategy Pattern）[④ 组件协作]
(23) 访问者模式（Visitor Pattern）[⑧ 行为变化]
(24) 模板模式（Template Pattern）[④ 组件协作]
附编程发散思维图：
ref
https://ld246.com/article/1566313342510
－End－
