设计模式_14
我就是画画草稿图就开始写代码的那个人，画图可以避免复杂度在大脑中“爆炸”。。。

# 感想：
在入门阶段，我们会遵照一些方法论来行事，比如
“寻找名词作为参数”，
“寻找动词作为方法”
...
这些方法通常都可以直接执行，一顿操作解决问题。
时间久了，我们开始思考：
- 为什么要这样做？
- 这些方法的本身优势是什么？

这个时候，我们才接近了分析的的本质，我们可能沿用这些方法，亦或找到更好的方法，不管怎样，都变得更通透。

对比一下整个流程，发现现在自己做的还是太草率了。

我也知道写代码其实是整个开发过程中最简单的一件事情，只要前期准备工作做的好，把该分析的都分析清楚，写代码自然就是水到渠成的事情。

但是我现在的做法是：

1. 拿到需求之后，先判断需求是否可以同项目中复用；
2. 然后拿一个小笔记本把涉及到的需求先设想下，包括类、DB等设计（用法很粗糙，没老师这么细致）
3. 用伪代码先把小流程实现
4. 写代码

这里的薄弱环节就是不知道如何更好的使用设计模式，从第三步直接到了第四步，而不存在软件工程中UML的设计，导致很多时候代码写了很多，也一直是在做面向过程的事情，而不是面向对象。

课程真的很赞，已经不能再夸了。好好跟着课程学习，收获满满，和同学们一起进步

1. 面向对象分析
* 产出是详细的需求描述

2. 如何进行面向对象设计
* 产出是类
* 划分职责进而识别出有哪些类
    * 根据需求描述拆解小功能点（单一职责），罗列出来
    * 找到功能相近、操作同样属性的可能归到一个类
    * 复杂的需求需要先拆分模块，然后再用这个方法找类

* 定义类及其属性和方法
    * 需求描述中动词作为候选方法、名次作为候选属性
    * 并不是所有名次都被定义为类的属性，不属于这个类的可以通过传参

* 定义类与类之间的交互关系
    1. 泛化（Generalization）
    简单理解为继承关系
    2. 实现（Realization）
    一般是指接口和实现类之间的关系
    3. 关联（Association）
    一种非常弱的关系，包含聚合、组合两种关系。如果 B 类对象是 A 类的成员变量，那 B 类和 A 类就是关联关系。
    4. 聚合（Aggregation）
    一种包含关系。A 类对象包含 B 类对象，B 类对象的生命周期可以不依赖 A 类对象的生命周期，比如课程与学生之间的关系。`public class A { private B b; public A(B b) { this.b = b; }}`
    5. 组合（Composition）
    一种包含关系。A 类对象包含 B 类对象，B 类对象的生命周期跟依赖 A 类对象的生命周期，B 类对象不可单独存在，比如鸟与翅膀之间的关系`public class A { private B b; public A() { this.b = new B(); }}`
    6. 依赖（Dependency）
    比关联关系更加弱的关系，包含关联关系。
* 将类组装起来并提供执行入口
    * 独立系统的话可以是main函数
    * 可以是一组给外部调用的API接口

整体看下来对真正面向对象编程好像有了正确的理解， 不过单独自己去实现的时候，又不不会那么周到，还是文中所说，需要练习和经验。