Java设计模式-UML与设计原则（1）

    大家好，我是馆长！在正式讲解Java设计模式之前，馆长先整理了一些概要信息，方便大家了解和学习。了解这些技术和理论信息，可以为设计模式的讲解更加的透彻与易学。

   简介

        统一建模语言（Unified Modeling Language，UML）是用来设计软件蓝图的可视化建模语言，1997 年被国际对象管理组织（OMG）采纳为面向对象的建模语言的国际标准。它的特点是简单、统一、图形化、能表达软件设计中的动态与静态信息。
        UML 定义了用例图、类图、对象图、状态图、活动图、时序图、协作图、构件图、部署图等9 种图。
    

    各位看官可以使用 Umlet工具或者StartUML等 ，IDEA可以使用PlantUML插件使用，它是一个轻量级的开源 UML 建模工具，简单实用，常用于小型软件系统的开发与设计。

定义

1、用例图

        用例图是需求分析的产物，主要是用来描述用户是如何使用一个系统的，是用户所能观察和使用到的系统功能的模型图。

2、类图

        UML类图，是用来描述系统中的类以及各个类之间的关系。系统中可以有多个类图，单个类图则只是表达了系统的一个方面。类图可以帮助我们在正确编写代码之前对系统有个很全面的认识，是建模中最常见的一种类型图。

3、对象图

        对象图描述的是一组对象之间的关系，而不是类之间的关系。它是类图的变体，但是又与之不同，对象显示的类的多个对象而不是实际的类。

4、活动图

        UML活动图，顾名思义就是UML的动态模型的一种图形，对于系统的功能建模特别重要。它用来描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。简单来讲，就是表示在处理某个活动时，两个或者更多类对象之间的过程控制流。

5、状态图

        UML状态图，用于显示状态，即描述一个对象所处的可能状态以及状态之间的转移。用状态图建模可以帮助开发人员分析复杂对象的各种状态的转换，以及对象何时执行怎样的动作。

6、时序图

        UML时序图，又叫序列图或者顺序图，是一种用来描述对象之间传送消息的时间顺序，是用来表示用例中的行为顺序。

7、协作图

        UML协作图(又叫通信图)是一种作用于显示对象之间如何进行交互以执行特点用例或用例中特点部分行为的交互图，它强调的是发送和接收消息的对象之间的组织结构。

8、组件图

        UML组件图(又叫构件图)，是用来描述在软件系统中遵从并实现一组接口的物理的、可替换的软件模块。它所表现的是一种系统静态实现的结构，能够帮助开发人员对系统组成达成一致的认识。

9、部署图

        UML 部署图是一个用来描述系统的硬件配置和部署以及软件的构件和模块在不同节点上分布的模型图。它能够帮助系统相关人员了解系统中各个构件部署在什么硬件上以及硬件之间的交互关系。

类、接口和类图

1. 类            

        类（Class）是指具有相同属性、方法和关系的对象的抽象，它封装了数据和行为，是面向对象程序设计（OOP）的基础，具有封装性、继承性和多态性等三大特性。在 UML 中，类使用包含类名、属性和操作且带有分隔线的矩形来表示。
(1) 类名（Name）是一个字符串，例如，Student。
(2) 属性（Attribute）是指类的特性，即类的成员变量。UML 按以下格式表示：

关于 访问权限的符号表示

" + " 表示public访问权限

" - " 表示private访问权限

" # " 表示protected

" ~ " 表示default,也就是包权限(有的软件用 * 标识 package )

2. 接口

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

3. 类图

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

类之间的关系

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

1. 依赖关系

        依赖（Dependency）关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。
        在 UML 类图中，依赖关系使用带箭头的虚线来表示，由依赖方指向被依赖方。

2. 关联关系

        关联（Association）关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系。如：爸爸和儿子；丈夫和妻子等。关联关系是类与类之间最常用的一种关系，分为一般关联关系、聚合关系和组合关系。我们先介绍一般关联。
        关联可以是双向的，也可以是单向的。在 UML 类图中，双向的关联可以用带两个箭头或者没有箭头的实线来表示，单向的关联用带一个箭头的实线来表示，箭头从关联类指向被关联类。也可以在关联线的两端标注角色名，代表两种不同的角色。

单向关联如下：

双向关联如下：

3. 聚合关系

        聚合（Aggregation）关系是关联关系的一种，是强关联关系，是整体和部分之间的关系，是 has-a 的关系。
    聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。
在 UML 类图中，聚合关系可以用带空心菱形的实线来表示，菱形指向整体。

4.组合关系

        组合（Composition）关系也是关联关系的一种，也表示类之间的整体与部分的关系，但它是一种更强烈的聚合关系，是 contains-a 关系。在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在。如：年与月的关系；时/分/秒的关系。
        在 UML 类图中，组合关系用带实心菱形的实线来表示，菱形指向整体。

5.泛化关系

        泛化（Generalization）关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系，是 is-a 的关系。
        在 UML 类图中，泛化关系用带空心三角箭头的实线来表示，箭头从子类指向父类。

6.实现关系

        实现（Realization）关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。
        在 UML 类图中，实现关系使用带空心三角箭头的虚线来表示，箭头从实现类指向接口。

七大设计原则    

        接下来，馆长开始介绍 7 种设计原则，分别为开闭原则、里氏替换原则、依赖倒置原则、单一职责原则、接口隔离原则、迪米特法则、合成复用原则。

        在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据 7 条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。

1.开闭原则

定义

       开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出：软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。

        开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

这里的软件实体包括以下几个部分：

1.项目中划分出的模块

2.类与接口

3.方法

  

2.里氏替换原则

定义

        里氏替换原则（Liskov Substitution Principle，LSP）由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在 1987 年的“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstraction and Hierarchy）里提出来的，她提出：继承必须确保超类所拥有的性质在子类中仍然成立（Inheritance should ensure that any property proved about supertype objects also holds for subtype objects）。
    里氏替换原则主要阐述了有关继承的一些原则。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。

        里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。

3.依赖倒置原则

定义

      依赖倒置原则（Dependence Inversion Principle，DIP）是 Object Mentor 公司总裁罗伯特·马丁（Robert C.Martin）于 1996 年在 C++ Report 上发表的文章。

        依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口编程，不要面向实现编程。

        依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。

4.单一职责原则

定义

        单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。

5.接口隔离原则

定义

        接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。
        2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on methods they do not use）。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。

简单来说就是实现以下要求：

 ·接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。

·为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。

 ·提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

    

6.迪米特法则

定义

        迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。
        迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
    迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

从迪米特法则的定义和特点可知，它强调以下两点：

    1.从依赖者的角度来说，只依赖应该依赖的对象。

    2.从被依赖者的角度说，只暴露应该暴露的方法。

7.合成复用原则

定义

        合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。

        总的来说，这 7 种设计原则是软件设计模式必须尽量遵循的原则，各种原则要求的侧重点不同。其中，开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；单一职责原则告诉我们实现类要职责单一；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合度；合成复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用。

    好了，本章馆长就先介绍到这里。谢谢各位看官！！

        馆长准备了很多学习资料，其中包含java方面，jvm调优，spring / spring boot /spring cloud ，微服务，分布式，前端，js书籍资料，视频资料，以及各类常用软件工具，破解工具 等资源。请关注“IT技术馆”公众号，进行关注，馆长会每天更新资源和更新技术文章等。请大家多多关注。