面向对象基本方法_面向对象方法-优快云博客

本文链接：https://blog.youkuaiyun.com/m0_55661792/article/details/142431104

一、面向对象基础

对象的定义

对象是运行的实体，通常可由对象名、属性（数据）和方法（数据的操作、行为）三个部分组成。对象的状态标识了该对象的所有属性（通常是静态的）以及每个属性的当前值（通常是动态）

对象基础需求分析的相关概念

对象	在开发时会将人、物等都抽象为对象，人、物的特性会变成对象的属性，对象还有相关的操作方法，即这个人（物）在系统内部可以做些什么；对象由标识属性和服务构成，他们被封装为一个整体以接口的形式对外提供服务
类	将多个对象的共性抽取出来形成类，一个类中的对象都是这个类的实列，没有实例的类是抽象类，抽象类不能被实例化，不能用new关键字。建立丰富的类库是程序设计成熟的重要标志
	实体类：人、物等实体
	边界类：具有与外界交互职能的类
	操控类：类与类之间需要衔接，因此需要控制类来控制衔接
抽象	抽取事务的本质特征
封装	例如对程序中一部分属性封装起来作为私有，如果外部想要访问这些属性需要通过固定接口
继承和泛化	继承：子类继承父类的全部特征
继承和泛化	泛化：将有共性的几个类提取共性形成一个上层类
多态	同样的操作去控制不同的对象，对象的表现状态不一样，例如快速移动操作，控制对象狗表现状态是跑，控制鱼表现状态是游；其中参数多态和包含多态称为通用多态，过载多态和强制多态称为特定多态
接口	接口是一种特殊的类，此种类只有方法的定义没有实现，相当于空条例
消息	对象之间进行交互的时候采用的机制，采用异步方式传输
组件	组件就是构件，是面向软件架构体系可以复用的模块
模式和复用	模式：经验累积形成的模板
模式和复用	复用：重复使用

面向对象分析与设计

面向对象分析基于用例模型包括三个活动：

建模系统功能→发现并确定业务对象→组织对象并确定关系

面向对象设计是在分析基础上设计各个对象、对象之间的关系、通信方式等

二、面向对象设计原则

注：一般考选择

单一职责原则	设计目的单一的类	一个类解决一个问题，类与其他类的联系较少，程序的耦合度低
开放-封闭原则	对扩展开放，修改封闭	维护过程中，最好是拓展新的类实现新功能而不是修改原有的类，因为修改原有类可能会引入新的错误
李氏替换原则	子类可以替换父类	不要盲目修改父类
依赖倒置原则	编程针对抽象和接口，不针对实现	依赖实现编程，改动时会有大的牵连
接口隔离原则	使用多个专门的接口	一个接口做一件事，使问题简单化不易出错
组合重用原则	尽量使用组合，而不是继承关系达到重用目的	继承中，父类变化子类需要跟着变，比较麻烦
迪米特原则 (最少知识法则)	一个对象应当尽可能少的了解其他对象	使用封装，使部分属性私有不对外界展示，各模块之间了解较少使用接口进行连接

三、设计模式的基本概念

架构模式

软件设计中的高层决策，从全局看待问题，例如C/S结构，架构模式反映了开发软件系统过程中所作的基本设计决策

惯用法

最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件之间的关系，每种编程语言都有自己特定的模式，即语言的惯用法。

设计模式

主要关注软件系统的设计，从局部看待问题，与具体实现语言无关

设计模式的分类

创建型模式

用于创建对象的模式，为创建类的实例化的新对象提供指南。

抽象工厂模式 Abstract Factory	提供一个接口类型，可以创建一系列相关或相互依赖的对象，无需指定他们具体的类。（不止是类模式，也可以是对象模式）
构建器模式 Builder 生成器模式	将一个复杂类的表示与其构造相分离，使得相同的构建过程能得出不同的表示。构造过程必须允许被构造的对象有不同的表示。
工厂方法模式 Factory Method	定义一个创建对象的接口，由子类决定需要实例化哪一个类，工厂方法使得子类实例化过程推迟
原型模式 Prototype	用原型实例指定创建对象类型，拷贝原有对象生成新的对象，例如直接复制源代码改一下生成新代码比重新敲一遍源代码要快
单例模式 Singleleton	保证一个类只有一个实例，比如浏览器中可以打开多个标签页，但是当前显示的只有一个页面

结构型模式

处理类或对象的组合问题，为类或对象形成更大的结构提供指导。

适配器模式 Adapter	将一个类的接口进行转换，使原本不相容的接口可以协同工作（不止可以是类模式，也可以是对象模式）	转换接口
桥接模式 Bridge	将类的抽象部分和他的实现部分分离，使他们可以独立变化	继承树拆分
组合模式 Composite	将对象组合成树形结构，来表示整体和部分的层次结构，使用户对单个对象和对象的使用具有一致性	树形目录结构
装饰模式 Decorator	动态地给一个对象添加一些额外的职责，可以替代子类的扩展功能，且比派生子类更加灵活	附加职责
外观模式 Facade	定义一个高层接口，为系统中的接口提供一个一致的外观，简化该子系统的使用	对外统一接口
享元模式 Flyweight	提供支持大量细粒度对象共享的有效方法
代理模式 Proxy	为其他对象提供一种代理以控制这个对象的访问

行为型模式

一组对象以定义良好但复杂的方式通信，产生的依赖关系结构混乱且难以理解。

职责链模式 Chain of Responsibility	将接收对象连接起来形成链，发送者发送消息通过链中对象依次传递，直到有对象能回复，可以减少发送者与接收者之间的耦合
命令模式 Command	把待执行请求封装成对象，实现动作的参数化，对请求进行排队或记录日志并支持撤销。
解释器模式 Iterpreter	给定一种语言，定义他的文法表示，并定义一个解释器，该解释器用来根据文法表示解释语言中的句子（不止可以是类模式，也可以是对象模式）
迭代器模式 Iterator	提供一种方法，来顺序访问一个聚合对象中的各个元素，而不需要暴露该对象的内部表示
中介者模式 Mediatir	用一个中介对象对一些对象进行交互，使各对象不需要显示地相互调用，从而降低耦合，还可以独立地改变对象间的交互
备忘录模式 Memento	不破坏封装性的前提下捕获对象内部状态，并在该对象之外进行保存，从而可以在以后将该对象进行恢复
观察者模式 Observer	定义对象之间的一对多关系，当一个对象的状态发生改变时，所有依赖于他的对象都得到通知并自动更新
状态模式 State	将状态做成类，类的改变可以改变当前的行为
策略模式 Strategy	定义一系列算法，把他们各自封装，使他们之间可以相互替换，让算法可以独立于用户变化
模板方法模式 Template Method	定义一个操作中的算法骨架，将一些步骤延迟到子类当中，使子类可以不改变一个算法结构即可重新定义算法的某些特定步骤（不止可以是类模式，也可以是对象模式）
访问者模式 Visitor	一个作用于某对象结构中的各元素的操作，在不改变元素的类的前提下定义作用于这些元素

四、数据流图DFD

又称分层数据流图，常用于需求分析阶段。注意与程序流程图区分，流程图主要用于详细设计用来描述程序的逻辑结构。

图例

图例需要记牢，有时会将E-R图等多种图的图例混合出选择。

分层

数据流图的分层一般是分为顶层图、0层图、最底下的子图。上层图与下层图（或称之为父图与子图）需要保持平衡。数据流图的封层是从顶到下逐层进行分解，此分解思路与结构化的开发方法完全吻合，所以数据流图成为了结构化方法里面最常用的工具

顶层图

中间椭圆表示需要开发的程序，两侧方框表示该程序与外部实体进行的交互。

0层图

在顶层图基础上，对需开发程序细化，将整体程序拆分成部件。

底层子图

在0层的基础上，对部件进行进一步细化。

逻辑数据流图

是物理数据流图去掉了所有的物理细节后得到的变换形式，逻辑数据流图被用作系统进行分析的数据分析阶段的起点。

物理数据流图

关注系统中的物理实体以及一些具体的文档、报告和其他输入输出硬拷贝。物理数据流图用作是系统构造和实现的技术性蓝图。

数据字典

数据字典用来配合数据流图的使用，对一些数据或名词进行相应的诠释。

符号	含义	例子
+	与	a+b 表示 a 与 b，即 a 和 b
=	被定义为	机票=姓名+日期+航班号+起点+终点+费用；表示：元素姓名、日期、航班号、起点、终点、费用被定义为机票
[......，......] [......\|......]	或	x=[a，b]、x=[a \| b]，表示x由a组成或者由b组成
{......}	重复	x={a}，x由0个或者多个a组成
（......）	可选	x=（a），表示a可以在x中出现，也可以不出现

决策树

在描述加工方式中表示加工涉及的多个逻辑条件

数据流图平衡原则

父图与子图之间的平衡

数据流图的平衡原则是上层图与下层图（父图与子图）之间，凡是在上层数据流图中出现的交互，在下层数据流图中也必须出现，且方向、数量、名词都需一致。

例如下图顶层数据流图中，外部组织前端应用，与需开发程序数据管理之间有6个箭头，那么在此图细化而成的0层数据流图中，二者之间的交互也应该是6个箭头，并且箭头的名词、方向、数量都需相同。另外两个外部交互组织，数据管理员、后端数据库也需要遵循此原则。

注：由数据需开发程序，数据管理中间件细化而成的内部交互与此无关。

子图内平衡

子图内平衡是指在加工这一项操作中，如果有输入必须有输出才能算作平衡，有输入无输出称作黑洞；无输出有输入称作奇迹；还有一种是输入与输出不对等，或者输出与输入不对等；此三者都属于不平衡，在数据流图中违背平衡原则是错误的。

例

关于数据流图的平衡原则一般的考察方式是给定上层图（或下层图），让判断下层图（或上层图）之间的交互对应关系有无缺失和错误，尤其注意有无箭头指向的方向错误，此错误容易忽略。

上图中红色代表上层图与下层图共有的交互，蓝色代表下层图中缺失的交互，绿色表示需开发程序的细化。如图中，下层图缺失2个上层图中存在的交互，此为不平衡。

数据流图考察

数据流图考察一般为大题类型，首要的是尽可能详细的分析题目中的题干信息，数据流图就是根据题干绘制而成的，然后再利用平衡原则查看是否有数据流方向问题，数据流是否缺失等。

五、UML建模

UML建模部分包含多种类型的图。考察方式一般为大题。

UML三部分

构造块

UML事物

结构事物是UML模型中的名词，通常是，模型的静态部分描述概念或物理元素。

行为事物是UML模型的动态部分，通常是，模型中的动词，描述跨越时间和空间的行为。

分组事物是UML模型的组织部分，通常是由模型分解成的盒子。

注释事物是UML模型的解释部分，通常是用来描述，说明模型的任何元素。

图

图分为：结构图（静态图）、行为图（动态图）

结构图（静态图）

行为图（动态图）

用例图

考察方式其一是根据题干将图做补充或者修改，其二是根据题干判断两个用例之间属于包含关系、扩展关系、泛化关系中的哪一种。

扩展关系：子用例→基础用例；

包含关系：基础用例→子用例；

类图

考察方式其一是根据题干信息填写类名、方法名、属性名；其二是填写多重度；其三是填关系。多重度和关系需要牢记。

类的种类

实体类：顾名思义就是实体

边界类：描述外部参与者与系统之间的交互

控制类：控制视线应用程序的执行逻辑

多重度

1	表示一个集合中的一个对象对应另一个集合中的一个对象，可以是数字2、3等意义同上
0..或	表示一个集合中的一个对象对应另一个集合中的0个或多个对象（可以是0个不对应）
1..*	表示一个集合中的一个对象对应另一个集合中的1个或多个对象（至少对应1个）
0..1	表示一个集合中的一个对象对应另一个集合中的0个或1个对象