面向对象

程序设计思想发展史">## 程序设计思想发展史

- 面向机器（打孔织带，汇编语言，load store add sub if goto ...）

- 面向过程（从load store中解放出来，关注业务逻辑，从具体的机器解放出来，增强了移植性和通用性，C fortran basic语言）

- 第一次软件危机，硬件飞速发展，代码应用复杂度越来越高，很多大项目都失败了，《人月神话》，出现软件工程的概念，出现结构化程序设计思想，主张自顶向下，逐步细化，模块化

- 第二次软件危机，硬件飞速发展，代码应用复杂度越来越高，很多大项目又失败了，软件生产力跟不上硬件发展速度，可扩展性，可维护性，出现面向对象的设计思想

### 面向过程

- 完成一件事情的多个步骤，流水线一样，例如：啤酒生产线，程序=数据结构+算法

- 驱动程序，协议栈，操作系统都是面向过程

- 主要缺点就是，扩展性差，修改不容易（啤酒生产线改生产醋，工业界少有，软件变化却非常快）

### 面向对象

- 更侧重与现实世界的模拟，程序=对象+交互

- 主要解决扩展性问题，如何更好的面对更加多变的需求，将变化带来的影响局限在有限的范围内，而不是全局都受影响

- 所以面向对象的用途就是那些经常变化的部分，集中在客户需求的部分

- 软件质量全景图：成本、性能、可靠性、安全性、可维护性、可移植性、可伸缩性、可扩展性，面向对象只负责可扩展性，其他问题一概不管

- cpu纳秒，内存微妙，磁盘网络毫秒级

- 面向对象语言和面向对象思想完全没关系，C一样可以面向对象，redis的AE驱动，面向接口编程就是面向对象，因为扩展性好

面向对象理论">## 面向对象理论

### 类

- 类是一组相似事物，如何划分取决于角度，名词是属性，动词是方法

- 属性最小化原则，不可划分原则

- 方法单一化原则，一个方法只做一件事情

### 对象

- 一个具体的类，一个真实存在的类

### 接口

- 一组相关的交互功能点定义的集合，一组多个，相关的操作封装在一起，交互必须对外

### 抽象类

- 更高层次的抽象

- 抽象类和接口，抽象类还是类，强调属性和方法的相似性，接口只强调方法的相似性

### 抽象

- 对象抽象为类

- 类抽象为超类

- 抽象的目的，隔离关注点，降低复杂度

### 封装

- 隔离隐私

- 隔离复杂度

### 继承

- 抽象反过来就是继承

- 遗传和变异

### 多态

- 使用指向父类的指针或引用，可以调用子类的方法

- 调用者可以代码不变的，依赖接口，写通用的代码，无须针对每个子类写不同的代码

面向对象分析和设计全流程概述">## 面向对象分析和设计全流程概述

- 需求模型，沟通，明确客户需求

- 领域模型，提出领域相关概念

- 设计模型，类的设计

- 实现模型，编码

### 需求模型

- 需求和功能的差异，需求是对用户有价值的事情，功能是为了实现客户价值而提供的能力

- 比如：ATM，存取款是需求，密码验证是功能；汽车，驾驶是需求，发动机，刹车都是功能

- 需求阶段多花时间，修复问题的代价：编码阶段成本1，测试阶段5-10，维护阶段20，需求阶段0.1即可

- 需求分析的目的是挖掘客户的问题，实现客户价值，比如客户如果饿了，只会说我要一只羊，而不会说我饿了，我饿了是问题，我要一只羊是需求对你的，解决客户的问题

- 三重境界需求分析：记录员，XX客户需要一只羊，品种是绵羊，颜色是白色，重量20kg；分析员，XX客户肚子饿了，需要一只羊烤着吃，由于客户不会烤，我们需要提供烤好的羊；引导员，客户饿了，要烤羊，夏天膻味中，更愿意吃海鲜啤酒大餐=

- 需求分析的方法5W1H8C， when where who what why how 8c 性能...，how时用用例方法

- 用例方法 use case，NEA方法正常normal处理，异常处理，替代处理，用例应当包括：名称+场景+描述+价值+约束和限制条件

- NEA三种用例完成后，需求分析基本完成，接下来提取功能，把用例中的动词提取出来就是功能，功能要和用例一一关联，用表格

- 用例图，可以用SSD系统顺序图，类似时序图画出来，UML的用例图则不是描述用例的而是描述系统的

- 用例是站在业务流程角度，SSD则是站在系统角度，描述系统和外部的交互，重点是系统

### 领域模型

- 领域模型是对领域内的概念或现实世界的对象的可视化表示，又称概念模型、分析对象模型、对象模型

- 1、发掘业务概念 2、建立业务领域概念之间的联系

- 简单一句话，才用例中找名词即可，然后提炼简化，然后给每个概念加属性，然后连关系，慢慢就有点面向对象的意思了

- 找名词、加属性、连关系

- 面向过程需要上述模型嘛，不需要，面向过程需要分析的是工作流和数据结构

### 设计模型

- 完成领域类到软件类的变化

- 主要包括静态模型和动态模型，静态模型就是类模型，类，属性，方法，类和类的关系

- 动态模型，类之间的配合，方法的具体实现过程

- step 1；how to？依赖领域模型，加上设计模式的应用即可

- 软件类来自领域类，领域类来自用例，用例来自客户需求，依次完成类筛选、名称映射、属性映射、提炼方法

- 方法的提炼主要来自于用例，用例中的动词就是方法的来源，找到所有动词，做筛选提炼，然后分配到设计好的类中

- step 2；应用设计原则和设计模式，精雕细琢（SOLID SRP单一职责原则、OCP开闭原则、LSP里氏替换原则、ISP接口隔离原则（多组特定接口优于单一宽泛的接口）、DIP依赖反转原则（依赖接口或抽象，不依赖具体实现））

- 违背原则，主要就会牺牲了可扩展性，也就牺牲了面向对象的最大优势

- 一般来说先用设计原则，设计类的定义、后设计模式指导类的行为设计

- step3；拆分辅助类，比如MVC模式，MVVM模式等等

- 动态模型，在类设计完成后，对照用例，找一种合适的模型把用例表示出来

- 常见的模型，状态模型、活动模型、序列模型、协作模型

- 动态模型不要面面俱到，找准主要矛盾和需求点

### 实现模型

- C++,类、封装访问控制、友元、继承、多继承、虚拟继承、多态虚函数、抽象类-纯虚函数、接口-纯虚函数

- Java，万物皆对象、去除多继承、虚拟继承、虚函数，直接区分类、接口、抽象类，多态override即可

面向对象技巧">## 面向对象技巧

### 设计原则

- 内聚：指一个模块内部元素彼此结合的紧密程度

- 专注模块的职责的时候，即内聚

- 偶然内聚（utils misc这种）、逻辑内聚、时间内聚（异常处理函数）、过程内聚（A-》B-》C）、信息内聚（增删改查）、顺序内聚（流水线式）、功能内聚（http协议解析、xml解析等等）

- 耦合：程序模块相互之间的依赖程度

- 无耦合（只有最底层的才有可能）、消息耦合（子系统之间的rpc、类之间的方法调用都算，要看模块是什么，不传参数是关键）、数据耦合（传递基本类型参数）、数据结构耦合、控制耦合（消息+行为控制参数）、外部耦合（操作系统与外设）、全局耦合（共享全局变量）、内容耦合

- 原则就是高内聚、低耦合，why，1、降低复杂度、使得人类可以理解，2、同时最大的要点就是扩展性，也是隔离性，一个类变化的时候，其他的类因为耦合都得跟着改代码，就是不好了，也失去了扩展性

- 基于高内聚低耦合的总体原则，梳理出常用的设计类的原则

- SRP 单一职责，一个类只负责一组相关的事情，用于类的设计

- OCP 开闭原则，不修改代码就能增加新功能，对提供者增加新的功能，使用者原来的代码不受影响，例如接口、协议的不变性，总的指导思想

- LSP 里氏替换原则，子类必须可以无感知替换父类，比如配置管理，从xml json 数据库来是实现的事，类之间的继承关系

- ISP 接口隔离原则，类可以提供更多接口，但是客户端依赖的时候可以依赖一个子集，抽象为单独的接口，最少原则，指导接口的设计

- DIP 依赖反转原则，高层模块不应该依赖底层模块，两者都应该依赖共同的抽象层，抽象不能依赖细节，细节依赖抽象，依赖关系

- NOP 不要过度使用设计原则，过犹不及，太过预知未来的变化，工作量也几何倍数递增，要有个度的把握，避免过度设计

### 设计模式

- 解决复用性问题、主要领域是面向对象

- 设计模式的根本思想就是：对变化的概念进行封装，找到变化，封装变化，就是核心理念，哪里有变化，哪里就有设计模式的用武之地，反之则不然

- 基于接口、而不基于实现；优先有组合而非继承

### UML统一建模语言

- 用例图

- 静态图：类图、继承、实现、关联、依赖、组合聚合

- 动态图：状态图、时序图、协作图、活动图

- 结构图、组件图、部署图

面向对象架构设计">## 面向对象架构设计

- 架构是系统的结构和组织，架构是系统级别的顶层结构

- 7+-2原则，人类最多关注5-9个事物，架构设计为了隔离关注点，降低复杂度、架构设计为了分工协作

- 架构设计就是将复杂系统拆分为模块、设计模块职责、通信协议 架构=模块+交互

### 面向对象架构设计流程

- 业务架构、领域架构、软件架构

- 业务架构：全新的（从需求中中来）、升级优化

- 业务需求分功能性需求和质量需求，qps，并发等等为质量需求

- 领域架构，在业务架构基础上、提取业务模块、确定业务模块之间的关系

- 软件架构：1、照领域架构猫画软件架构虎 2、拆分子系统、根据需求或设计约束做更多的拆分 3、评估所有备选方案优缺点，挑选最优方案

### 面向对象架构设计技巧

- 客户需求优先原则

- 适当超前原则，预测未来的变化或需求，唯一不变的就是变化

- 设计架构的倚天屠龙，拆和合，拆：加机器，拆子系统，拆模块，拆完之后要保证合，即拆解玩的各个模块要有机的融合在一起

- 拆硬件，拆功能，拆地点

- 合，客户端合，提供统一SDK，网络合DNS，中间件合，数据库中间件，子系统合

- 最后就是创新的能力，创造力，建立在广博的知识积累下，知道的越多，思维就越开阔，做出优秀设计的概率就越大