UML可视化建模语言，面向对象设计原则

本文主要是介绍UML可视化建模语言，面向对象设计原则，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

UML可视化建模语言，面向对象的设计原则

- 建模语言
- 面向对象的设计原则

建模语言

建模语言（Unified Modeling Language，UML）是用来设计软件蓝图的可视化建模语言，1997 年被国际对象管理组织（OMG）采纳为面向对象的建模语言的国际标准.建模语言能为软件开发的所有阶段提供模型化和可视化支持。而且融入了软件工程领域的新思想、新方法和新技术，使软件设计人员沟通更简明，进一步缩短了设计时间，减少开发成本简而言之：UML 类图以可视化图形方式来表述类与类之间的关系,方便理解.类图的基本元素

1. 类

是指具有相同属性、方法和关系的对象的抽象，它封装了数据和行为，是面向对象程序设计（OOP）的基础，具有封装性、继承性和多态性等三大特性。在 UML 中，类使用包含类名、属性和操作且带有分隔线的矩形来表示。

(1) 类名（Name）是一个字符串，例如，Student。

(2) 属性（Attribute）是指类的特性，即类的成员变量。UML 按以下格式表示：

[可见性]属性名:类型[=默认值]

例如：-name:String

注意：“可见性”表示该属性对类外的元素是否可见，包括公有（Public）、私

有（Private）、受保护（Protected）和朋友（Friendly）4 种，在类图中分别

用符号+、-、#、~表示。

(3) 操作（Operations）是类的任意一个实例对象都可以使用的行为，是类的成员方法。UML 按以下格式表示：

[可见性]名称(参数列表)[:返回类型]

例如：+display():void。

学生类的 UML 表示

在这里插入图片描述

2. 接口

接口（Interface）是一种特殊的类，它具有类的结构但不可被实例化，只可以被子类实现。它包含抽象操作，但不包含属性。它描述了类或组件对外可见的动作。在 UML 中，接口使用一个带有名称的小圆圈来进行表示。图形类接口的 UML 表示

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D5as3ECo-1678859450232)(C:\Users\封纪元\AppData\Roaming\Typora\typora-user-images\1642511759994.png)]$

3. 类图

类图（ClassDiagram）是用来显示系统中的类、接口、协作以及它们之间的静态结构和关系的一种静态模型。它主要用于描述软件系统的结构化设计，帮助人们简化对软件系统的理解，它是系统分析与设计阶段的重要产物，也是系统编码与测试的重要模型依据。类图中的类可以通过某种编程语言直接实现。类图在软件系统开发的整个生命周期都是有效的，它是面向对象系统的建模中最常见的图。下图所示是“计算长方形和圆形的周长与面积”的类图，图形接口有计算面积和周长的抽象方法，长方形和圆形实现这两个方法供访问类调用

在这里插入图片描述

类之间的关系

在软件系统中，类不是孤立存在的，类与类之间存在各种关系。根据类与类之间的耦合度从弱到强排列，UML 中的类图有以下几种关系：依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等，它们是最强的。

1.依赖关系

在A类中的某个方法中把B类作为参数使用,具有临时性.

在这里插入图片描述

2.关联关系

关联（Association）关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。关联关系是类与类之间最常用的一种关系，分为一般关联关系、聚合关系和组合关系。我们先介绍一般关联。

一般关联关系：

关联可以是双向的，也可以是单向的。在 UML 类图中，双向的关联可以用带两个箭头或者没有箭头的实线来表示，单向的关联用带一个箭头的实线来表示，箭头从使用类指向被关联的类。也可以在关联线的两端标注角色名，代表两种不同的角色。

在代码中通常将一个类的对象作为另一个类的成员变量来实现关联关系。下图所示是老师和学生的关系图，每个老师可以教多个学生，每个学生也可向多个老师学，他们是双向关联

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-byCdVBJ7-1678859450235)(C:\Users\封纪元\AppData\Roaming\Typora\typora-user-images\1642512474074.png)]$

聚合关系：

聚合（Aggregation）关系是关联关系的一种，是强关联关系，是整体和部分之间的关系，是 has-a 的关系。

聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如，学校与老师的关系，学校包含老师，但如果学校停办了，老师依然存在

在 UML 类图中，聚合关系可以用带空心菱形的实线来表示，菱形指向整体。下图所示是大学和教师的关系图。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YG7aycCf-1678859450235)(C:\Users\封纪元\AppData\Roaming\Typora\typora-user-images\1642512629502.png)]$

组合关系：

组合（Composition）关系也是关联关系的一种**，也表示类之间的整体与部分的关系，但它是一种更强烈的聚合关系，是 contains-a 关系。**

在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在。例如，头和嘴的关系，没有了头，嘴也就不存在了

在 UML 类图中，组合关系用带实心菱形的实线来表示，菱形指向整体。下图所示是头和嘴的关系图。

在这里插入图片描述

3.泛化关系

泛化（Generalization）关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系，是 is-a 的关系。

在 UML 类图中，泛化关系用带空心三角箭头的实线来表示，箭头从子类指向父类。在代码实现时，使用面向对象的继承机制来实现泛化关系。例如， Student 类和 Teacher 类都是 Person 类的子类，其类图下图所示。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WSTfr8MR-1678859450237)(C:\Users\封纪元\AppData\Roaming\Typora\typora-user-images\1642512856158.png)]$

4.实现关系

实现（Realization）关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。

在 UML 类图中，实现关系使用带空心三角箭头的虚线来表示，箭头从实现类指向接口。例如，汽车和船实现了交通工具，其类图如下图所示。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1bB62bGl-1678859450237)(C:\Users\封纪元\AppData\Roaming\Typora\typora-user-images\1642512981930.png)]$

面向对象的设计原则

在面向对象的设计过程中，首先需要考虑的是如何同时提高一个软件系统的可维护性和可复用性。这时，遵从面向对象的设计原则，可以在进行设计方案时减少错误设计的产生，从不同的角度提升一个软件结构的设计水平

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hUos2MKc-1678859450238)(C:\Users\封纪元\AppData\Roaming\Typora\typora-user-images\1642513281205.png)]$

单一职责

单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小。

对于单一职责原则**，可以理解为一个类只负责一个功能领域中的相应职责，即一个类不要负责太多“杂乱”的工作**。在软件系统中，如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时设计或遭受到意想不到的破坏。以项目开发为例，如果项目组成员每个人的职责都很明确，可以专心开发自己负责的模块，则项目成果的质量往往很高。相反，如果职责不清晰，分工就会混乱。

优点: 低耦合,高内聚。

开闭原则

开闭原则是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则

开闭原则即对扩展开放，对修改封闭。在软件系统开发过程中，软件的需求往往会随着时间的推移而发生变化。因此，进行软件设计时需要考虑怎样的设计才能面对需求的改变却可以相对保持稳定，从而使得系统可以在第一个版本以后不断推出新的版本。这时便可以以开闭原则作为指导。如果一个软件设计符合开闭原则，那么可以非常方便地对系统进行扩展，而且在扩展时无须修改现有代码， 使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。

为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。在进行软件设计时，一般先评估出最有可能发生变化的类，然后构造抽象来隔离那些变化。当变化发生时，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。

总结就是：

对扩展开发,对修改关闭

抽象功能,具体的实现可以扩展子类.

优点:

适应性和灵活性

稳定性和延续性

可复用性与可维护性

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-10ZxFJkH-1678859450239)(C:\Users\封纪元\AppData\Roaming\Typora\typora-user-images\1642513612149.png)]$

里氏替换原则（多态）

里氏代换原则是实现开闭原则的重要方式之一。

在任何父类出现的地方都可以用它的子类来替换，且不影响功能(多态)。

只有当子类可以替换其父类，软件单位的功能不受影响时，父类才能被真正复用，而子类也能够在父类的基础上增加新的行为。同时，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

在使用里氏代换原则时需要注意如下问题：

(1) 子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。

(2) 在运用里氏代换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，从而可以很方便地扩展系统的功能

依赖倒置

高层模块不应该依赖底层模块，两者都应该依赖其抽象；抽象不应该依赖细节；

细节应该依赖抽象。

也就是针对抽象层编程，面向接口编程。

在顶层不适合定义太多的功能,底层实现有的可能用不到的.

在中间设计接口,抽象类去扩展功能,底层按照自己的需要去实现即可.

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3SvJHzu4-1678859450240)(C:\Users\封纪元\AppData\Roaming\Typora\typora-user-images\1642514044229.png)]$

接口隔离

使用多个专门的接口，而不使用单一的总接口，不强迫新功能实现不需要的方法

class cpu{ }

class 内存{ }

class 硬盘{ }

电脑

cpu

内存

硬盘

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jRxPgopt-1678859450240)(C:\Users\封纪元\AppData\Roaming\Typora\typora-user-images\1642514185768.png)]$

迪米特原则

一个对象应当对其他对象尽可能少的了解,降低耦合。

使用代理的思想,不直接对其他类进行访问

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v1QgSZNS-1678859450241)(C:\Users\封纪元\AppData\Roaming\Typora\typora-user-images\1642514251749.png)]$

组合/聚合复用原则

优先使用组合，使系统更灵话，其次才考虑继承，达到复用的目的。

一般而言，如果两个类之间是"Has-A"关系应使用组合或聚合，如果是"Is-A"关系可使用继承。

总结

七大原则虽说是原则，但它们并不是强制性的，更多的是建议。遵照这些原则固然能帮助我们更好的规范我们的系统设计和代码习惯，但并不是所有的场景都适用，就例如接口隔离原则，在现实系统开发中，我们很难完全遵守一个模块一个接口的设计，否则业务多了就会出现代码设计过度的情况，让整个系统变得过于庞大，增加了系统的复杂度，甚至影响自己的项目进度。

这篇关于UML可视化建模语言，面向对象设计原则的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！