一、设计模式七大准则

1、设计模式的目标

编写软件过程中，程序员面临着来自 耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性 等多方面的挑战，设计模式是为了让程序(软件)，具备更好

  • 1) 代码重用性 (即：雷同性能的代码，不必屡次编写)
  • 2) 可读性 (即：编程规范性, 便于其余程序员的浏览和了解)
  • 3) 可扩展性 (即：当须要减少新的性能时，十分的不便，称为可保护)
  • 4) 可靠性 (即：当咱们减少新的性能后，对原来的性能没有影响)
  • 5) 使程序出现高内聚，低耦合的个性分享金句：
  • 6) 设计模式蕴含了面向对象的精华，“懂了设计模式，你就懂了面向对象分析和设计（OOA/D）的精要”
  • 7) Scott Mayers 在其巨著《Effective C++》就已经说过：C++新手和 C++老手的区别就是前者手背上有很多伤疤

2、设计模式七大准则

设计模式准则，其实就是程序员在编程时，该当恪守的准则，也是各种设计模式的根底(即：设计模式为什么这样设计的根据)

➢设计模式罕用的七大准则有:

  • 1、繁多职责准则
  • 2、接口隔离准则
  • 3、依赖倒转准则
  • 4、里氏替换准则
  • 5、开闭准则 ocp
  • 6、迪米特法令
  • 7、合成复用准则

2.1 繁多职责准则

对类来说的，即一个类应该只负责一项职责。如类 A 负责两个不同职责：职责 1，职责 2。当职责 1 需要变更而扭转 A 时，可能造成职责 2 执行谬误，所以须要将类 A 的粒度合成为 A1，A2。

繁多职责准则注意事项和细节：
1) 升高类的复杂度，一个类只负责一项职责。
2) 进步类的可读性，可维护性
3) 升高变更引起的危险
4) 通常状况下，咱们该当恪守繁多职责准则，只有逻辑足够简略，才能够在代码级违反繁多职责准则；只有类中办法数量足够少，能够在办法级别放弃繁多职责准则

2.2 接口隔离准则(Interface Segregation Principle)

客户端不应该依赖它不须要的接口，即一个类对另一个类的依赖应该建设在最小的接口上

2.3 依赖倒转准则

依赖倒转准则(Dependence Inversion Principle)是指：

  • 1) 高层模块不应该依赖低层模块，二者都应该依赖其形象
  • 2) 形象不应该依赖细节，细节应该依赖形象
  • 3) 依赖倒转(倒置)的中心思想是面向接口编程
  • 4) 依赖倒转准则是基于这样的设计理念：绝对于细节的多变性，形象的货色要稳固的多。以形象为根底搭建的架构比以细节为根底的架构要稳固的多。在 java 中，形象指的是接口或抽象类，细节就是具体的实现类
  • 5) 应用接口或抽象类的目标是制订好标准，而不波及任何具体的操作，把展示细节的工作交给他们的实现类去实现。
示例

计划1，一般示例（未应用依赖倒转）：

package com.atguigu.principle.inversion;public class DependecyInversion {   public static void main(String[] args) {    Person person = new Person();    person.receive(new Email());}}class Email {   public String getInfo() {     return "电子邮件信息: hello,world";   }}//实现 Person 接管音讯的性能//形式 1 剖析//1. 简略，比拟容易想到//2. 如果咱们获取的对象是 微信，短信等等，则新增类，同时 Perons 也要减少相应的接管办法//3. 解决思路：引入一个形象的接口 IReceiver, 示意接收者, 这样 Person 类与接口 IReceiver 产生依赖//    因为 Email, WeiXin 等等属于接管的范畴，他们各自实现 IReceiver 接口就 ok,  这样咱们就符号依赖倒转准则class Person {   public void receive(Email email ) {      System.out.println(email.getInfo());   }}

实现计划2（依赖倒转）

package com.atguigu.principle.inversion.improve;public class DependecyInversion {public static void main(String[] args) {  //客户端无需扭转  Person person = new Person();  person.receive(new Email());  person.receive(new WeiXin());}}//定义接口interface IReceiver {     public String getInfo();}class Email implements IReceiver {    public String getInfo() {     return "电子邮件信息: hello,world";}} //减少微信class WeiXin implements IReceiver {    public String getInfo() {     return "微信信息: hello,ok";   }}//形式 2class Person {//这里咱们是对接口的依赖public void receive(IReceiver receiver ) {     System.out.println(receiver.getInfo());}}

依赖倒转准则的注意事项和细节:
1) 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好.
2) 变量的申明类型尽量是抽象类或接口, 这样咱们的变量援用和理论对象间，就存在一个缓冲层，利于程序扩大和优化
3) 继承时遵循里氏替换准则

2.4 里氏替换准则

2.4.1 OO 中的继承性的思考和阐明

1) 继承蕴含这样一层含意：父类中但凡曾经实现好的办法，实际上是在设定标准和契约，尽管它不强制要求所有的子类必须遵循这些契约，然而如果子类对这些曾经实现的办法任意批改，就会对整个继承体系造成毁坏。

2) 继承在给程序设计带来便当的同时，也带来了弊病。比方应用继承会给程序带来侵入性，程序的可移植性升高， 减少对象间的耦合性，如果一个类被其余的类所继承，则当这个类须要批改时，必须思考到所有的子类，并且父类批改后，所有波及到子类的性能都有可能产生故障

3) 问题提出：在编程中，如何正确的应用继承? => 里氏替换准则

2.4.2 根本介绍

1) 里氏替换准则(Liskov Substitution Principle)在 1988 年，由麻省理工学院的认为姓里的女士提出的。
2) 如果对每个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。换句话说，所有援用基类的中央必须能通明地应用其子类的对象。

3) 在应用继承时，遵循里氏替换准则，在子类中尽量不要重写父类的办法
4) 里氏替换准则通知咱们，继承实际上让两个类耦合性加强了，在适当的状况下，能够通过聚合，组合，依赖来解决问题。

2.5 开闭准则

2.5.1 根本介绍

1) 开闭准则（Open Closed Principle）是编程中最根底、最重要的设计准则
2) 一个软件实体如类，模块和函数应该对扩大凋谢(对提供方)，对批改敞开(对应用方)。用形象构建框架，用实现扩大细节。

3) 当软件须要变动时，尽量通过扩大软件实体的行为来实现变动，而不是通过批改已有的代码来实现变动。
4) 编程中遵循其它准则，以及应用设计模式的目标就是遵循开闭准则。

2.6 迪米特法令

2.6.1 根本介绍

1) 一个对象应该对其余对象放弃起码的理解
2) 类与类关系越亲密，耦合度越大
3) 迪米特法令(Demeter Principle)又叫起码晓得准则，即一个类对本人依赖的类晓得的越少越好。也就是说，对于被依赖的类不论如许简单，都尽量将逻辑封装在类的外部。对外除了提供的 public 办法，不对外泄露任何信息
4) 迪米特法令还有个更简略的定义：只与间接的敌人通信

5) 间接的敌人：每个对象都会与其余对象有耦合关系，只有两个对象之间有耦合关系，咱们就说这两个对象之间是敌人关系。耦合的形式很多，依赖，关联，组合，聚合等。其中，咱们称呈现成员变量，办法参数，办法返回值中的类为间接的敌人，而呈现在局部变量中的类不是间接的敌人。也就是说，生疏的类最好不要以局部变量的模式呈现在类的外部。

2.6.2 迪米特法令注意事项和细节

1) 迪米特法令的外围是升高类之间的耦合
2) 然而留神：因为每个类都缩小了不必要的依赖，因而迪米特法令只是要求升高类间(对象间)耦合关系， 并不是要求齐全没有依赖关系

2.7 合成复用准则（Composite Reuse Principle）

2.7.1 根本介绍

准则是尽量应用合成/聚合的形式，而不是应用继承。

3、设计准则核心思想

  • 1) 找出利用中可能须要变动之处，把它们独立进去，不要和那些不须要变动的代码混在一起。
  • 2) 针对接口编程，而不是针对实现编程。
  • 3) 为了交互对象之间的松耦合设计而致力

二、UML类图

1 UML 根本介绍

  • 1) UML——Unified modeling language UML (对立建模语言)，是一种用于软件系统剖析和设计的语言工具，它用于帮忙软件开发人员进行思考和记录思路的后果
  • 2) UML 自身是一套符号的规定，就像数学符号和化学符号一样，这些符号用于形容软件模型中的各个元素和他们之间的关系，比方类、接口、实现、泛化、依赖、组合、聚合等，如右图

在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

先看看UML图的根本关系示意:

关系阐明：

  • 继承关系(Generalization)；
  • 实现关系(Realization)；
  • 依赖关系(Dependency)；
  • 关联关系(Association)；
  • 有方向的关联(DirectedAssociation)；
  • 聚合关系(Aggregation)；
  • 组合关系(Composition)；

相干文章：

疾速学习UML类图查看