设计原则

单一职责原则

一个类只负责一项内容

  1. 降低类的复杂度，一个类只负责一项职责。
  2. 提高英的可读性，可维护性
  3. 降低变更引起的风险
  4. 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则;只有类中方法数量足够少，可以在方法级别保持单一职贲原则

接口隔离原则

客户端不应该依赖它不需要的接口，即一今类耐另一个类的依赖应该建立在最小的接口上

依赖倒转原则

  1. 高层模块不应该依赖低层模块,二者都应该依赖其抽象
  2. 抽象不应该依赖细节，细节应该依赖抽象
  3. 依赖倒转(倒置)的中心思想是面向接口编程
  4. 依赖倒转原则是基于这样的设计理念:相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类,细节就是具体的实现类
  5. 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

依赖倒转原则的注意事项和细节

  1. 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好.
  2. 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化
  3. 继承时遵循里氏替换原则

里氏替换原则

  1. 继承包含这样一层含义:父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些己经实现的方法任意修改，就会对整个继承体系造成破坏。
  2. 绊承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所露承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障

尽量不要重写父类方法 原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖，聚合，组合等
关系代替.

开闭原则

开闭原则(Open Closed Principle）是编程中最基础、最重要的设计原则

  1. 一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭（使用方）。
  2. 用抽象构建框架，用实现扩展细节。
  3. 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
  4. 编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。

（活用接口，抽象类）

迪米特法则

  1. 一个对象应该对其他对象保持最少的了解
  2. 类与类关系越密切，耦合度越大
  3. 迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息
  4. 迪米特法则还有个更简单的定义:只与直接的朋友通信
  5. 直接的朋友:每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系:我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

此规则 只是要求降低耦合度 不是完全无依赖

合成复用原则

原则是尽量使用合成/聚合的方式，而不是使用继承

依赖(Dependency)关系是类与类之间的联接：体现为局域变量、方法的形参，或者对静态方法的调用
关联(Association）关系是类与类之间的联接:它使一个类知道另一个类的属性和方法,一般使用成员变量来实现，有时也用方法形参的形式实现,(1对多，1对1…)
聚合(Aggregation) 关系是关联关系的一种，是强的关联关系:聚合关系也是通过实例/成员变量实现的。但是关联关系所涉及的两个类是处在同一层次上的，而在聚合关系中，两个类是处在不平等层次上的，一个代表整体，另一个代表部分
组合(Composition) 关系是关联关系的一种，是比聚合关系强的关系：它要求普通的聚合关系中代表整体的对象负责代表部分对象的生命周期，组合关系是不能共享的；，代表部分的对象在每一个时刻只能与一个对象发生组合关系，由后者排他地负责生命周期。部分和整体的生命周期一样

如何区分 聚合和组合 ： 如果整体和部分 可以分开 则是 聚合，如果不行 是组合

区别在于成员变量 是否默认绑定，即 new或者初始化，如果参数仅通过其他方式注入，则是聚合，否则是组合

泛化（继承）， 实现

原则总结

  1. 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
  2. 针对接口编程，而不是针对实现编程。
  3. 为了交互对象之间的松耦合设计而努力

UML

名词解释

image.png

依赖：

  1. 如果是方法的返回类型
  2. 是方法接收的参数类型
  3. 方法中使用到

设计模式概述

设计模式分为三种类型，共23种

  1. 创建型模式:单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式。
  2. 结构型模式:适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
  3. 行为型模式:模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式(Interpreter模式)、状态模式、策略模式、职责链模式(责任链模式)。

模式不是代码，而是某类问题的通用解决方案,设计模式的本质提高软件的维护性，通用性和扩展性，并降低软件的复杂度

单例

饿汉式（静态常量）（通常情况最方便）

  1. 构造器私有化(防止new )
  2. 类的内部创建对象 向外暴露一个静态的公共方法 getInstance

image.png

优缺点说明:

  1. 优点:这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。
  2. 缺点:在类装载的时候就完成实例化，没有达到Lazy Loading的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费
  3. 这种方式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，在单例模式中大多数都是调用getInstance方法，但是导致类装载的原因有很多种，因此不能确定有其他的方式（或者其他的静态方法）导致类装载,这时候初始化instance就没有达到lazy loading的效果
  4. 结论:这种单例模式可用，可能造成内存浪费

饿汉式（静态代码块）（跟静态常量没区别）

image.png
这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块
中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例

懒汉式（线程不安全）（少用）

image.png
优缺点：

  1. 起到了Lazy Loading的效果，但是只能在单线程下使用。
  2. 如果在多线程下，一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式
  3. 结论:在实际开发中，不要使用这种方式.

懒汉式（线程安全、同步方法）不推荐

image.png
优缺点说明:

  1. 解决了线程不安全问题
  2. 效率太低，多线程环境互锁 ，每个线程在想获得类的实例时候，执行getInstance()方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例，直接return就行了。方法进行同步效率太低
  3. 结论:在实际开发中，不推荐使用这种方式

懒汉式（线程安全、同步代码块）禁止使用

image.png
优缺点说明:

  1. 这种方式，本意是想对第四种实现方式的改进，因为前面同步方法效率太低，改为同步产生实例化的的代码块
  2. 但是这种同步并不能起到线程同步的作用。跟第3种实现方式遇到的情形一致，假如一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例
  3. 结论:在实际开发中，不能使用这种方式

懒汉式（双重检查）(由于JVM底层内部模型原因，偶尔会出问题，不建议使用)

image.png
优缺点说明:

  1. Double-Check概念是多线程开发中常使用到的，如代码中所示，我们进行了两次if (singleton’== null)检查，这样就可以保证线程安全了。
  2. 这样，实例化代码只用执行一次，后面再次访问时，判断if (singleton == null),直接return实例化对象，也避免的反复进行方法同步.
  3. 线程安全;延迟加载;效率较高

懒汉式（静态内部类）（无法传参，看应用场景）

image.png

优缺点说明:

  1. 这种方式采用了类装载的机制来保证初始化实例时只有一个线程。
  2. 静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getldstance方法，才会装载SingletonInstance类，从而完成Singleton的实例化。
  3. 类的静态属性只会在第一次加载类的时候初始化，所以在这里，ⅣM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。
  4. 优点:避免了线程不安全，利用静态内部类特点实现延迟加载，效率高

懒汉式（枚举）（jdk1.5推荐，内存占用翻倍）

image.png

优缺点说明:

  1. 这借助JDK1.5中添加的枚举来实现单例模式。不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。
  2. 这种方式是Effective Java作者Josh Bloch提倡的方式

一般情况下，不建议使用懒汉式-同步方法，建议使用 标准的第一种饿汉式。只有在要明确实现 lazy loading 效果时，才会使用静态内部类方式。如果涉及到反序列化创建对象时，可以尝试使用枚举方式。如果有其他特殊的需求，可以考虑使用双检锁方式

单例模式注意事项和细节说明

  1. 单例模式保证了系统内存中该类只存在一个对象，节省了系统资源，对于一些需要频繁创建销毁的对象，使用单例模式可以提高系统性能
  2. 当想实例化一个单例类的时候，必须要记住使用相应的获取对象的方法，而不是使用new
  3. 单例模式使用的场景:需要频繁的进行创建和销毁的对象、创建对象时耗时过多或耗费资源过多(即:重量级对象)，但又经常用到的对象、工具类对象、频繁访问数据库或文件的对象(比如数据源、session工厂等)

工厂模式

简单工厂

  1. 优点是比较好理解，简单易操作。

  2. 缺点是违反了设计模式的ocp原则，即对扩展开放，对修改关闭。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码.

  3. 简单工厂模式是属于创建型模式，是工厂模式的一种。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式

  4. 简单工厂模式:定义了一个创建对象的类，由这个类来封装实例化对象的行为(代码)
  5. 在软件开发中，当我们会用到大量的创建某种、某类或者某批对象时，就会使用到工厂模式.

工厂方法模式

工厂方法模式设计方案:将项目的实例化功能抽象成抽象方法，在不同的口味点餐子类中具体实现。
工厂方法模式:定义了一个创建对象的抽象方法，由子类决定要实例化的类。工厂方法模式将对象的实例化推迟到子类。

image.png

抽象工厂

1）抽象工厂模式:定义了一个interface用于创建相关或有依赖关系的对象簇，而无需指明具体的类2)抽象工厂模式可以将简单工厂模式和工厂方法模式进行整合。
3)从设计层面看，抽象工厂模式就是对简单工厂模式的改进(或者称为进一步的抽象)。4)将工厂抽象成两层，AbsFactory(抽象工厂)和具体实现的工厂子类。程序员可以
根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇，更利于代码的维护和扩展。