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