1. 前题回顾

1.1 UML图的使用阶段



1.2 架构师的职责与要求

• 架构师的实质不在于title/工资/公司实际地位，在于实际，其它人的工作必须依赖你，需求搞不定了需要来找你，有技术问题需要来找你

• 架构师需要由破局的能力，能重新引导出方向

• 用户/老板/业务方是看不懂代码的，需要给出一些东西（比如架构设计文档）能支持他们的信心，让他们相信你

• 不能让别人乱推你，不能光跟着别人的想法跑



2. 编程的本质与未来

2.1 编程语言的实质

• 编程的目的：使用计算机来解决现实世界的问题

• 编程的过程即：在计算机所能理解的“模型”（解空间）和现实世界（问题空间）之间，建立一种联系

• 编程语言是一种“抽象”的机制，问题是对“谁”来抽象



2.2 什么是对象

Booch对于对象的描述：对象具有状态、行为和标识

• 状态：每个对象可以有自己的数据

• 行为：每个对象可以产生行为

• 标识：每个对象都区别于其它的对象（唯一的地址）



2.3 面向对象的三要素（特征）

• 封装性（Encapsulation）

• 隐藏实现细节（访问控制）

• 定义接口

• 继承性（Inheritance）

• IS-A关系

• HAS-A关系（组合）

• 多态性（Polymorphism）

• 后期绑定（虚函数）

• 向上转形（Up Casting）

封装和继承都不是OOP独有的，C语言也有类似机制

多态也不是面向对象独有的，因为有指向函数的指针，多态事实上在C语言中也可以实现

多态是OOP的核心



3. 软件设计原则

3.1 面向对象编程与面向对象分析

面向对象编程不是使用面向对象的语言进行编程，而是利用多态特性进行编程

面向对象分析是将客观世界，即编程的业务领域进行对象分析

• 充血模型和贫血模型

• 领域驱动设计DDD

3.2 框架（Framework）

框架是用来实现某一类应用的结构性程序，是对某一类架构方案可复用的设计与实现

• 如同框架结构的大厦框架

• 简化应用开发者的工作

• 实现了多种设计模式，使应用开发者不需要花费太大的力气，就能设计出结构良好的程序来



3.3 框架 VS 工具

• 框架

• 框架调用应用程序代码

• 架构师用框架来保证架构的落地（框架是落地的保证）

• 工具

• 应用程序代码调用工具

• 架构师用工具来提高开发效率



3.4 软件设计的好与坏

软件设计的最终目的，是使软件达到“强内聚，松耦合”，从而使软件

• 易扩展 - 易于增加新的功能

• 更强壮 - 不容易被粗心的程序员破坏

• 可移植 - 能够在多样的环境下运行

• 更简单 - 容易理解、容易维护

不好的软件则会

• 僵硬 - 不易改变

• 脆弱 - 只想改A，结果B被意外破坏

• 不可移植 - 不能适应环境的变化

• 导致误用的陷阱 - 做错误的事比正确的事更容易，引诱程序员破坏原有的设计

• 晦涩 - 代码难以理解

• 过度设计

• copy-paste代码

• 等等



4. OOD原则

4.1 开/闭原则（OCP）

OCP - Open / Closed Principle

• 对于扩展是开放的（Open for extension）

• 对于更改是封闭的（Closed for modification）

• 简而言之，不需要修改软件实体（类、模块、函数等），就应该能实现功能的扩展

当我有需求变更/扩展/增加新功能，都是可以的，开放的，但是不会去修改现有代码

改进方法

• 策略模式

• 适配器模式

• 观察者模式

4.2 依赖倒置原则（DIP）

DIP - Dependency Inversion Principle

• 高层模块不能依赖低层模块，而是大家都依赖于抽象

• 抽象不能依赖实现，而是实现依赖抽象

DIP 倒置了什么

• 模块和包的依赖关系

• 开发顺序和职责

软件的层次化

• 高层决定低层

• 高层被重用

controller依赖service接口，service是低层模块，粗暴方式是把service的东西刚在controller层就可以了，关键是倒置的抽象是属于谁的，正确做法是service面向业务定义接口

高层来定义，低层来实现



改进方式



4.3 Liskov替换原则（LSP）

4.4 单一职责原则（SRP）

4.5 接口分离原则（ISP）

4.6 迪米特法则/最少知道原则(LKP)



5. 扩展阅读



敏捷软件开发 - 原则、模式与实践