从零开始单排学设计模式「UML类图」定级赛

阅读本文大概须要 3.5 分钟。

本篇是设计模式系列的开篇，虽然以前也写过相应的文章，可是由于种种缘由后来断掉了，并且发现以前写的内容也很渣，不够系统。

因此如今打算重写，加上距离如今也有一段时间了，也算是本身的一个回顾吧！

学而时习之，不亦说乎。

从零开始单排学设计模式的国服排位之旅，今天正式开启！

目前段位：定级赛

这篇文章来总结下UML类图，原本不打算讲UML类图的，由于我在学习设计模式的时候，一遇到有关UML的就会自动忽略，一看感受就很复杂。

可是随着学习的深刻，发现不掌握UML类图，对设计模式或者某一个框架没有总体的把控。因此与其逃避，不如勇于面对，今天就让咱们一块儿来了解下什么是UML类图。

Let's Go！

前言

设计模式不是语法，是一种巧妙的写法，能把程序变的更加灵活。架构模式比设计模式大，架构模式是战略，而设计模式是战术。

设计模式分为3大类型：建立型，行为型，结构型，总共有23种。

UML类图

类图描述系统中类的静态结构，它不只定义系统中的类，描述类之间的联系，如关联、依赖、聚合等，还包括类的内部结构（类的属性和操做）。

类图描述的是静态关系，在系统的整个生命周期中都是有效的。

对象图是类图的实例，它们的不一样之处在于对象图显示类图的多个对象实例，而不是实际的类。因为对象存在生命周期，因此对象图只能在系统某一时间存在。

UML基本图示法

虚线箭头指向依赖；

实线箭头指向关联；

虚线三角指向接口；

实线三角指向父类；

空心菱形能分离而独立存在，是聚合；

实心菱形精密关联不可分，是组合；

上面是UML的语法，在画类图的时候，清理类和类之间的关系是重点。

类的关系有泛化(Generalization)、实现（Realization）、依赖(Dependency)和关联(Association)。

其中关联又分为通常关联关系和聚合关系(Aggregation)，合成关系(Composition)。

基本概念

类图（Class Diagram）：类图是面向对象系统建模中最多见和最重要的图，是定义其余图的基础。

类图的主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。

类图的3个基本组件：类名、属性、方法。

详细解析

注：下面图片实例中的代码为C#代码，非Java代码！

继承关系

首先看到上图这个“动物”矩形框，它就表明一个类（Class）。

类图分三层

第一层显示类的名称，若是是抽象类，则就用斜体显示。

第二层是类的特性，一般就是字段和属性。

第三层是类的操做，一般是方法或行为。

在看到上图中的“飞翔”，它表示一个接口图，与类图的区别主要是顶端有<<interface>>显示。

第一行是接口名称，第二行是接口方法。

接口还有另外一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。

鸭子原本也有语言，只不过只有唐老鸭是能讲人话的鸭子。

注意动物、鸟、鸭、唐老鸭之间的关系符号，你就会发现它们都是继承的关系。

继承关系用空心三角形+实现来表示。

这里列举的几种鸟中，大雁是最能飞的，我让它实现了飞翔接口。

实现接口用空心三角形+虚线来表示。

在看下图中企鹅和睦候两个类，企鹅是很特别的鸟，会游不会飞。更重要的是，它与气候有很大的关联。咱们不去讨论为何北极没有企鹅，为何它们要每一年长途跋涉。

总之，企鹅须要“知道”气候的变化，须要“了解”气候规律。

当一个类“知道”另外一个类时，能够用关联（association）。

关联关系用实现箭头来表示。

咱们再来看上图中大眼与雁群这两个类，大雁是群居动物，每只大雁都属于一个雁群，一个雁群能够又不少只大雁。

因此它们之间就知足聚合（Aggregation）关系。

聚合表示一种弱的“拥有”关系，体现的是A对象能够包含B对象，但B对象不是A对象的一部分。

聚合关系用实心的菱形+实线箭头来表示。

合成（Composition，也有翻译成“组合”的）是一种强的“拥有”关系，体现了严格的部分和总体的关系，部分和总体的声明周期同样。

在这里鸟和其翅膀就是合成（组合）关系，由于它们是部分和总体的关系，而且翅膀和鸟的声明周期是相同的。

合成关系用实心的菱形+实现箭头来表示。

另外，你会注意到合成关系的连线两端还有一个数字“1”和数字“2”，这被称为基数。代表这一段的类能够有几个实例，很显然，一个鸟应该有两只翅膀。

若是一个类可能有无数个实例，则就用“n”来表示。关联关系、聚合关系也能够有基数的。

动物几大特征，好比有新陈代谢，能繁殖。而动物要有生命力，须要氧气、水以及食物等。也就是说，动物依赖于氧气和水。

他们之间是依赖关系（Dependency），用虚线箭头来表示。

结语

编程是一门技术，更加是一门艺术！

不能只知足于写完代码运行结构正确就完事，时常考虑如何让代码更加简练，更加容易维护，容易扩展和复用，只有这样才能能够真正获得提升。

切身感悟：本身几个月以前写完的代码，如今再来回顾，你会发现这代码简直了...，一团糟，甚至怀疑这代码不是出自本身之手（绝对是本身写的）。想着手优化，进行改进，又怕原本没问题的功能，改出问题，影响使用，而后又进入恶性循环了。。。这种状况要切记，必定要尽量的避免！

写出优雅的代码也是一种很爽的事情！！！

---

往期精彩回顾

房东：你敢申报，我就涨房租！京东取消年终奖！

一千行MySQL详细学习笔记（值得学习与收藏）

你女友是高可用么？

在Java中如何优雅地判空

最近整个业内状态不太好，注意提防一些公司的小九九！

Java爬取并下载酷狗TOP500歌曲

如何计算服务器可以承受多大的pv？

程序员们，别再学习框架了！

专科程序员与本科程序员之间有什么区别？

程序员的一天是怎样过的？

从 0 开始手写一个Tomcat，7 步搞定！

关注个人公众号阅读更多精彩！！！