面向对象
2019-11-27 10:09:41 1 举报AI智能生成
面向对象设计原则
作者其他创作
大纲/内容
面向对象理论
类
属性
指类具有的特征
属性最小化原则，即"属性不可再分"
方法
指类具有的功能
方法单一化原则，即"一个方法只做一件事"
对象
一个具体的类，有一个真实存在的类
接口
接口中的功能点实时定义，并不涉及具体实现
接口是一个交互协议，是交互双方的一个约定，具体实现，由具体的交互实体各自实现即可
抽象类
抽象类只能用于继承，不能被实例化为具体对象
抽象类是基于类而抽象出来的
抽象类有的存在抽象方法(方法只有声明，没有定义)，子类必须自己定义这些抽象方法，而不能像普通的方法一样，通过继承就可以获取父类的方法
抽象类本质上还是类，强调一组事物的相似性，包括属性和方法的相似性；而接口只强调方法的相似性，并且仅仅体现在方法声明省的相似性，而没有方法定义上的相似性
三大核心特征
封装
public
protected
private
继承
类似生物学上的"遗传"
多态
使用指向父类的指针或者引用，能够调用子类的对象
需求模型
通过和客户沟通，结合行业经验和知识，明确客户端的需求
目的
了解客户需要什么？？
需求分析目的
记录员
记录客户的需求
分析员
和客户一起分析问题，完善需求
引导员
能够引导客户的需求
需求分析的方法
5W
When
季节信息
日期信息
作息时间
Where
国家、地区
室内、室外、街道
建筑物
Who
常见的参与者信息
投资者、管理者
使用者、维护者
监督者、评估者
其他系统
举例：ATM
顾客：使用ATM取款、存款
银行维护人员:每天将钱放进ATM
质检机构：根据XX法律对ATM进行检查
What
一个文档
一份报告
一个系统
Why(最关键)
1H
How
使用用例分析
8C
性能
成本
时间
可靠性
安全性
合规性
技术性
兼容性
用例方法
用例方法三段法
正常处理
异常处理
代替处理
完整的用例
简单的样例：POS机
为什么要将功能点单独提取出来呢？
一个功能列表肯定比一长篇用例文档方便的多
从项目管理的角度来说，功能列表更易于管理，例如任务分配时不可能基于用例进行分配，因为不同用例可能存在大量重复的功能点
从开发的角度来说，开发时基于工功能点的，而不是基于用例的
从测试角度来说，虽然最后的验收测试时基于用例的，但产品测试主要还是基于功能点进行测试的
用例图
Actor
系统外的用户，对应5W中的Who，包括但不限于用户、外系统
Use Case
用例，对应前面讲到的用例
System
系统，所有用例的集合就是系统了
SSD
用于描述在某个用例的某个分支场景下，外部参与者与系统的交互过程
SSD不是标准的UML图形，UML只有顺序图、用例图，但是没有专门的"系统顺序图"；之所以叫作"系统顺序图"，是因为这个顺序图中只有两类对象。系统与系统交互的对象。
SSD用来描述某个用例的分支，而不是描述系统的结构
画SSD的时候，整个系统被当作一个黑盒，不涉及系统的分解
不需要为每个用例的每个分支都画一个SSD，调出关键的用例和分支即可
领域模型
找名词
例如：买单
顾客
收银员
收银台
商品
扫描仪
条形码
子主题
加属性
连关系
问题
为什么在POS机的领域模型的类中没有看到类的方法呢?
如果没有用例，是否就没法得到领域模型？
设计模型
静态模型
第一步（照猫画虎）: 领域类映射
类筛选
名称映射
将领域类转换为软件类，一对一转换
属性映射
直接从领域明星搬过来
提炼方法
分配
将从用例中提炼出来的动词，分配给已经有有了属性的软件类
第二步（精雕细琢）:应用设计原则和设计模式
设计原则
单一职责原则
开闭原则
里氏替换原则
接口隔离原则
依赖反转原则
第三步(照本宣科)：拆分辅助类
比如常见的MVC模式（Control、Model、View）
动态模型
状态模型
活动模型
顺序图
实现模型
面向对象技巧
设计原则
内聚
耦合
什么是模块？
函数
类
包
子模块
子系统
什么是依赖？
就是某个模块用到了另外一个模块的一些元素
耦合的分类
消息耦合
消息？？
系统/子系统
类
数据耦合
通过参数传递，而不是通过去哪聚文件、配置文件、共享内存等其他方式
传递的基本数据类型，例如在java中传递Integer、double/String 等类型，而不是传递数据结构
数据结构耦合
传递的是数据结构数据
控制耦合
通过传入一个控制参数来控制函数的处理流程或者输出
外部耦合
两个模块依赖相同的外部数据格式、通信协议、设备接口时
全局耦合
当两个模块共享相同的全局数据时，称为全局耦合
高内聚低耦合
为什么要高内聚低耦合？？
高内聚低耦合是否意味着内聚越高越好、耦合越低越好？？
为什么该内聚和低耦合是冲突的？？
类设计原则
单一职责原则
只负责一组相关的事情
一个类有多个方法，这些方法是相关的
相关
举例："学生信息管理类"具有4个功能
开闭原则
不修改代码就能增加新功能
应用原则
接口不变：包括函数名、函数参数、函数返回值等
接口改变：已有函数修改名称、参数、返回值，或者增加新的函数。OCP都不再适应
通过接口交互
类之间应用OCP-使用interface进行交互
模块与模块、系统和系统之间-使用规定好的协议，不管是私有还是公开的
里氏替换原则
子类的对象提供了父类的所有行为，且加上子类额外的一些东西（可以是功能，也可以是属性）
当程序基于父类实现时，如果将子类替换父类而程序不需要修改，则说明符合LSP原则
使用原则
子类必须实现或者继承父类所有的公有方法，否则调用者调用了一个父类中有，而子类没有的方法，运行时就会出错
子类每个方法的输入参数必须和父类一样，否则调用父类的代码不能调用子类；
子类每个方法的输出(返回值、修改全局变量、插入数据库、发送网络数据等）必须不比 父类少，否则基于父类的输出做的处理就没法完成；’
接口隔离原则
建议客户端不需要知道整个类，只需要知道具有内聚接口的抽象父类即可；
依赖反转
高层模块不应该直接以来底层模块，两者都应该依赖抽象层
抽象不能依赖于细节，细节必须依赖于抽象
什么 是模块？
站在架构层的角度，模块可以指子系统
站在子系统的角度：模块可以指Module?component
站在模块的角度，模块可以指类
什么是依赖？
高层模块依赖底层模块：指的是高层模块需要调用底层模块的方法
高层模块依赖抽象层：指高层 模块基于抽象层编程；
低层模块依赖抽象层：指低层模块集成或者实现抽象层
细节依赖抽象
其实和上一个依赖是同一个意思
如何使用原则
SRP原则：用于类的设计
OCR原则：总的指导思想
LSP原则
用于指导类继承的设计
ISP原则
用于指导接口的设计
DIP原则
用于指导如何抽象
设计模式
设计模式之道
对变化的概念进行封装
设计原则主要用于指导"类的定义"的设计
设计模式主要用于指导"类的行为"的设计
UML
需求分析阶段
用例图
能够对象架构设计流程
业务架构
主要用于描述客户的业务总体架构
最初的架构就是对客户业务系统的模拟
举例：京东商城
京东商城在电视上他投放商品广告
客户通过看电视，获取商品信息
客户打电话给京东商城的客服下订单
京东商城的客服收到订单后，客服打电话给仓库管理员下出货单
...
业务约束和限制
性能
每秒能够处理10万个订单
成本
整套方案预算
可靠性
技术性
兼容性
领域架构
从业务架构中提取处理"领域架构"
提炼方法
提取业务模块
确定业务模块之间的关系
举例：京东商城
京东商城在电视上投放广告
客户通过看电视，获取商品信息
客户打电话给京东商城的客服下订单
......
提取模块后，再提炼出也亢模块间的关系
软件架构
第一步：照猫画虎
从 业务架构转换成软件架构
我们只需在领域架构的基础上将各个模块映射为子系统即可
举例：
将订单映射为订单子系统
将物流映射为物流子系统
.......
第二步：按图索骥
上一步业务功能需求已经能够满足，但业务的质量需求可能还是无法满足
业务质量属性
性能
可靠性
成本
......
架构师能够判断在初始架构中哪里可能不满足需求
架构师知道有哪些模式可以解决我们遇到的问题
第三步：深思熟虑
深思：全面评估各个备选方案的优劣点
熟虑：挑选更有的方案
架构设计原则
客户需求优先 原则
技术的
成本
可靠性
性能
可扩展性
可测试性
管理的
质量
投入
进度
人力水平
适当超前原则
架构设计屠龙刀
拆与合
拆
一个模块太复杂了，拆成两个、三个
一个模块处理太慢了，拆成两个、三个
一台机器处理太慢了，拆成两台机器，三台机器
一台机器可靠性太低了，拆成准备、冷备、集群
拆的常用手段
拆硬件
主备模式
负载均衡模式
软件类
Nginx、LVS、HAProxy,四层负载均衡(IP层负载均衡）、7层负载均衡（应用层负载均衡）
硬件类F5
网络类DNS
拆地点
同城多机房
跨城多机房
跨国多机房
拆功能
系统变的简单
改动影响小，方面各系统独立扩展
通过接口来控制变更，降低风险
子主题
合
客户端合
将客户端拆分后的系统合起来，
网络合
中间件合
子系统合
0 条评论
下一页
