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

笔记

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

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

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

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

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

  • 泛化(Generalization): 可简单理解成继承关系

  • 实现(Realization): 一般指接口和实现类之间的关系

  • 聚合(Aggregation): 是一种包含关系，A类对象包含B类对象，但B类对象的生命周期不依赖于A类对象的生命周期。

    1
2
3
4
5
6

    public class A {
    private B b;
    public A(B b) {
        this.b = b;
    }
}

  • 组合(Composition): 也是一种包含关系，A类对象包含B类对象，但B类对象的生命周期依赖于A类对象的生命周期。

    1
2
3
4
5
6

    public class A {
    private B b;
    public A() {
        this.b = new B();
    }
}

  • 关联(Association): 包含聚合和组合两种关系

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

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

    public class A { // 聚合(也是依赖)
    private B b;
    public A(B b) {
        this.b = b;
    }
}
或者
public class A { // 组合(也是依赖)
    private B b;
    public A() {
        this.b = new B();
    }
}
或者
public class A { // 依赖
    public void func(B b) { ... }
}

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

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

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

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

参考