编程的逻辑-用面向对象方法实现复杂业务需求

        虽然不少同学一直在使用面向对象的语言进行项目开发，但是在分析、设计和编码过程中不一定用是真正的OOA/OOD/OOP的思想，贫血模型由于快速高效易上手，使用的项目不在少数，而随着软件规模和业务复杂度的提升，业务层越来越难维护，也随着微服务边界划分的困难，急需一套方法论来指导解决问题，DDD重回人们的视野，充血模型的优势逐渐体现出来，DDD是OOD的延申和补充,就像 微服务是SOA的延申和补充一样，下面的是老吕的读书笔记，感兴趣的可以看看，书名是《编程的逻辑》，主要讲了面向对象方法论

一、面向对象

1、面向对象主要适用于解决软件的“可扩展性问题”

2、面向对象语言不等于面向对象编程

二、面向对象理论

类设计两个基本原则：属性不可再分；一个方法只做一件事。

抽象的主要目的是“隔离关注点，降低复杂度”。

封装、继承、多态是面向对象的三大核心特征。

1、封装

1）封装什么？

封装类的属性和类的方法

2）为什么要封装？

封装的主要原因是“保护隐私”和“隔离复杂度”。

为什么要封装属性？有什么好处？

一是不会暴露内部的具体属性，二是封装了属性后，对属性的获取和修改只能通过类的方法进行，相当于加了一层AOP，可以轻松对属性进行统一的加工处理。如果属性是开放的，那么就没有一个统一的地方能够对属性进行治理，比如有个属性由于需求变更，需要统一输出为另一种格式，如果调用方直接访问了属性，那么就需要修改很多地方进行一一处理，如果调用方统一使用了方法获取这个属性的，那么只需要在一个地方（get方法中）进行处理即可。

为什么要封装方法？

主要是为了“隔离复杂度”，每个类只需要关注自己负责的功能如何完成即可，如果需要其它类配合，那么只需要调用类的方法即可，而不需要了解其它类功能的具体实现。

面向过程=算法+数据结构

面向对象=对象+交互

2、继承

抽象和继承是前后衔接的关系，先有抽象，通过抽象得出类，后通过继承来表达抽象结果。

3、多态

多态的真正含义是：使用指向父类的指针或者引用，能够调用子类的对象。

多态的特性在面向对象领域具有十分重要的作用。多态屏蔽了字类对象的差异，使得调用者可以写出通用性的代码，而无须针对每个字类来写不同的代码。其实就是面向接口编程思想。

除了能够让代码清晰简洁，多态还有一个更加重要的作用：当增加新的子类时，调用者的代码无需变动就能适用新的子类。

三、面向对象分析和设计流程

1、需求模型

2、领域模型

3、设计模型

4、实现模型

四、需求模型

需求分析518方法=5W1H8C

5W=when+where+who+what+why

1H=How

8C=8个约束（Constraint）=性能、成本、时间、可靠性、安全性、合规性、技术性、兼容性

需求分析阶段是不区分面向对象还是面向过程的

产出：功能清单、用例图、

五、领域模型

领域建模三字经

找名词：从用例种找名词，从而得到实体

加属性：每一个实体都有哪些属性

连关系：实体之间的关系

和ER图有点类似，但是 这里的实体和表不一定是1对1的关系。

如果是ER图那纯粹就是面向数据建模了，这里是面向对象建模，有类似的地方但步等同。

领域建模是“需求到面向对象的桥梁”

从用例中可以找到领域建模的名词

不是所有属性都在用例中存在

领域模型中的领域类不是软件类，而只是用于描述领域的实体，不需要关注方法

产出：领域类以及领域类之间的关系

六、设计模型

设计模型主要包括两部分内容：静态模型和动态模型。

静态模型又称“类模型”，主要关注系统的静态结构，描述系统包含的类、类的名称、职责、属性、方法，以及类与类之间的关系。

动态模型关注系统的“动态”行为，其实就是每个方法内部的具体实现过程。

静态模型用于指导类的声明，包括类名称、属性名、方法名；

动态模型用于指导类的方法的实现；

1、静态模型（类模型=类以及关系图）

第一步，照猫画虎，领域类映射

【类筛选】

软件类是软件系统内部的一个概念，领域类是业务领域的概念，它们大部分情况下直接映射过来即可，但并不是绝对的。

【名称映射】

直接从领域类映射即可

【属性映射】

直接从领域类映射即可

【提炼方法】

概括起来就是：在用例模型中找动词，然后进行-》 筛选（并不是所有动词都是软件类的方法）-》提炼（除了一些明显的方法外，还要根据用例提炼一些隐藏的方法）-》分配（将方法分配到各个软件类中）

产出：软件类图以及类图之间的关系图

第二步，精雕细琢，应用设计原则和设计模式

产出：抽象优化后的软件类图和关系

第三步，照本宣科，拆分辅助类

2、动态模型（交互的逻辑，时序图）

1）模型分类

状态模型、活动模型、序列模型、协作模型

2）建模实践

时序图

3）建模技巧

a、不需要面面俱到，要做效率和效果两方面的考虑，只做关键的、核心的、复杂的功能 进行动态模型设计即可

b、模型不等于代码，模型的作用是保障 代码逻辑大方向的正确，不等于伪码

七、实现模型

用Java等面向对象语言编码实现

八、设计原则

1、内聚

2、耦合

3、高内聚低耦合

4、类设计原则（SOLID）

1）SRP

2）OCP

3）LSP

4）ISP

5）DIP

6）如何应用设计原则

7）NOP，不要过度设计原则

5、总结

1）内聚是指模块内部元素的“凝聚力”

2）是否专注模块的职责，才是内聚性的充要条件

3）内聚性不是越高越好

4）内聚关注模块内部的元素结合程度，耦合关注模块之间的依赖程度

5）无论是“低内聚”，还是“高耦合”，其本质都是“不稳定”

6）真正好的设计是在高内聚和低耦合之间进行平衡，在追求稳定的同时追求代码的复用，这就对模块和接口职责的划分提出了更高要求，需要有大局观，视野观

九、设计模式

1、设计模式只是一把锤子

2、设计模式之道

3、原则VS模式

4、模式详解

5、总结

1）设计模式解决的是“可复用”的设计问题

2）设计模式应用的领域是“面向对象”

3）设计模式之道：

一个中心：找到变化，封装变化

两个基本点：1、基于接口编程，而不是针对实现编程  2、优先使用对象组合，而不是类继承

4）设计原则主要用于指导“类的定义”的设计，而设计模式主要用于指导“类的行为”的设计

十、UML

1、需求分析阶段

用例图

用例图的关系

2、设计阶段

类图

类关系图

动态图

结构图

3、部署阶段

4、总结

1）画UML图不等于做设计

2）用例图不是描述用例的，而是直观的描述系统对外提供的功能

3）UML种类的关系有：继承/实现关系、依赖关系、组合关系、聚合关系、关联关系

4）依赖是比关联更强的一种关系

5）聚合和组合是比依赖更强的一种关系

6）UML的动态图包括：状态图、序列图、协作图、活动图

十一、实战案例：朋友圈“踩”

1、需求模型

1）5W分析

2）1H分析

3）8C分析

4）功能列表

2、领域模型

1）找名词

2）加属性

3）连关系

3、设计模型

1）系统设计

系统设计序列图通常关注正常流程和比较复杂的异常和分支流程

2）详细设计

详细设计包括：代码设计、存储设计、缓存设计、质量设计等

4、代码模型

5、总结：

1）无论目前项目采用何种运作方式，技术人员都可以按照518方法分析和理解需求

2）系统设计核心任务有两个：需求分解分配和子系统接口设计

3）一个用例可以对应1~N个系统功能

4）领域模型并不是和子系统划分一一对应的，每个子系统都可能有类似的领域类，区别在于实现细节不同