设计模式之美学习笔记13~14: OOA, OOD和OOP

2019-12-04

Design Patterns

今天继续打卡学习极客时间上的专栏“设计模式之美”，本篇是专栏第13, 14节的学习笔记，是专栏中介绍"面向对象"这一设计原则和设计思想的两节。

笔记 #

这两节分上、下两节主要介绍了面向对象分析(OOA)、面向对象设计(OOD)、面向对象编程(OOP)。

面向对象分析可以粗略的可作是需求分析。需求分析过程也应该以迭代方式进行，成为一个不断迭代优化的过程，也可融入MVP思想。面向对象分析产出的是详细的需求描述。

面向对象设计就是把需求描述转换为具体的类的设计:

划分职责进而识别出有哪些类
定义类及其属性和方法
定义类与类之间的关系
将类组装起来并提供执行入口

其中类与类之间的关系，UML中定义了六种关系:

泛化(Generalization): 可简单理解成继承关系
实现(Realization): 一般指接口和实现类之间的关系
聚合(Aggregation): 是一种包含关系，A类对象包含B类对象，但B类对象的生命周期不依赖于A类对象的生命周期。
```
1public class A {
2    private B b;
3    public A(B b) {
4        this.b = b;
5    }
6}
```
组合(Composition): 也是一种包含关系，A类对象包含B类对象，但B类对象的生命周期依赖于A类对象的生命周期。
```
1public class A {
2    private B b;
3    public A() {
4        this.b = new B();
5    }
6}
```
关联(Association): 包含聚合和组合两种关系

依赖(Dependency): 是一种比关联关系更弱的关系，但包含关联关系。

 1public class A { // 聚合(也是依赖)
 2    private B b;
 3    public A(B b) {
 4        this.b = b;
 5    }
 6}
 7或者
 8public class A { // 组合(也是依赖)
 9    private B b;
10    public A() {
11        this.b = new B();
12    }
13}
14或者
15public class A { // 依赖
16    public void func(B b) { ... }
17}

其实不必过于区分上面几种类与类之间的关系，我想很少有人完全能按标准画好UML中的类图，但是一般在纸上画出一个草稿即使格式不是完全严密，别人也能看懂，也能起到交流的作用，起到交流和沟通的作用就够了。

将类组装起来，提供一个统一执行入口，这个入口不一定是以main方式的形式提供，更多情况下可能是组装为一个供外部使用接口(Facade)

面向对象编程就是将前面的面向对象设计翻译成代码实现。

另外，软件开发本身就是一个不断迭代的过程，因此也不必严格按照OOA, OOD, OOP的顺序，很多情况下OOA, OOD不可能把所有细节描述很清楚，前期起到沟通和指导的作用就够了，几个迭代下来未必有时间重新回去同步更新之前画的UML图。

设计模式之美学习笔记13~14: OOA, OOD和OOP

2019-12-04

笔记 #

参考 #