Java设计模式(23种)

视频
马士兵更加精简一点

随看随记

七大设计原则

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

1. 代码重用性(即:相同功能的代码，不用多次编写
2. 可读性(即:编程规范性,便于其他程序员的阅读和理解
3. 可扩展性(即:当需要增加新的功能时，非常的方便，称为可维护
4. 可靠性(即:当我们增加新的功能后，对原来的功能没有影响
5. 使程序呈现高内聚，低耦合的特性

单一职责原则

• 我认为是使用功能的原子性
• 每个类只用一个职责，类似于数据库的第一范式，类仅有原子的作用。
• 当一个类有多个职责是，将这个类的功能进行拆分，或者对类中的方法进行分类修改。
• 主要还是为了解耦。

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

接口隔离原则

• 我认为是实现功能的原子性
• 我认为是要实现接口的原子性，一个接口仅仅实现自己需要的原则的一部分。通过一个类实现多个接口，来实现一个类的多种功能。
• 接口的功能不需要很大，否则会导致功能冗余。
• 一个类依赖(调用)了一个接口，这个接口应该是仅仅具有这个类的职责，而不应该有多余的职责。
• 一个类对另一个类的依赖应该建立在最小接口之上。
• A依赖B实现的接口，C依赖D实现的接口。A仅仅需要123方法，C需要145方法，如果按下面的这个图实现的话，则会导致B实现了4，5无用方法，D实现了2、3无用方法。
• 应该修改成这样，接口根据需要拆分成三个接口，B实现1、2接口，D实现1、3接口。这样A调用B时，不会有多余的4、5方法。C调用D时不会有多余的2、3方法。
• 

依赖倒转原则

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

依赖倒转的反例

• 
• 仅仅能接收Email，不能接收weixin等，需要有一个接口来解耦对特定类的依赖。这里的IReceiver表示所有的能够接收信息的对象要实现的接口。
• 

依赖倒转的的实现方式有三种

• 在下面三种方式种，IOpenAndClose都是对象相应的需要实现的功能，对于方法执行对象都要接收一个统一的接口ITV，处理的重点在于如何将这个实现了接口(ITV)的对象传入我们要执行或调用的方法。
• 接口传递：通过方法的输入接收接口对象。
• 
• 

• 构造方法传递：
• 通过构造函数传进来的接口对象的方法。
• 
• 

• setter方式传递(SpringIOC)：
• 通过setter()的方式接收接口对象。
  
  

里氏替换原则

• 父子方法功能要相同
• 子类和父类在方法的功能上完全相同时，才能使用里氏替换原则。强调的是父类与子类相同方法之间的透明性，是一种面向对象继承的一种原则。
• 在子类种尽量不要重写父类已实现的方法。
• 通常的做法是将这两个类都继承一个更大的基类baseClass，将原来的继承关系区掉，使用依赖，聚合，组合等方法来解决问题。

里氏替换原则反例

• 因为B继承了A，同时也继承了A方法，所以我们会理所当然的认为，fun1是实现的同一个功能，这样在我们使用的时候会误把B的fun1，也当作A的fun1方法，导致了问题。
• 

解决方案

• 将B进行升级，不再成为A的子类，而是和A平级，这样就不会有人认为A和B的fun1方法是一个方法。如果我们依然想使用A类的方法，就可以使用聚合的方式，通过调用a.fun1()来实现，或者使用依赖fun2(A a)的方式来解耦。
• 

开闭原则

• p16 ，自己看吧， 不太好描述。
• 对提供方扩展开放，对使用方修改关闭，即当要实现功能拓展的时候，需要尽量不要让使用方感受到修改的变化。
• 尽量通过拓展的方式而不是修改的方式。
• 视频中的解决方式是抽象出了一个公共抽象方法，来解决了这个问题。

迪米特法则

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

合成复用原则

• 尽量使用合成/聚合的方式，而不是使用继承的方式。
• 当A与B无关时，B仅仅想使用A的方法，这样就会导致，当对A进行扩展时，B不想要扩展，但是也会被动扩展。这不是我们想要的，因此使用依赖、组合、聚合的方式来进行解决。
• 
• 依赖(方法传输参数)
• 

• 聚合(通过setter注入属性的方式)
• 

• 组合(通过构造函数注入的方式)
• 

七大原则的核心思想

• 解耦:尽量减少不同类之间的侵入关系，尽量做到一个类修改不影响其他类。
• 复用:将共同有的方法拆解出来，不需要变化的代码混在一起。
• 抽象:要面向接口编程，对能够实现接口规范的都可以，而不要面向实现编程，这样就会导致仅仅针对某一个实例，而不是针对一批实例，导致服复用性差。（控制反转的主要思想）

UML类图

• 依赖：方法调用

• 

• 继承：extend

• 实现：implement

• 组合：属性和对象创建是不可分离的，构造方法注入属性(组装乐高)

• 聚合：属性和对象创建是可以分离的，set注入属性(一把筷子)

设计模式分类

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

创建型模式

• 以产生什么样的对象为重点

单例模式(SpringIOC Singleton)

• 很多对象仅仅需要一个就可以，并不需要频繁的创建销毁，这样可以节省内存和释放JVM资源
• 例如我们仅仅需要一个factory对象就可以了
• 如果private static Singeton instance 在懒汉式中不可以使用final，因为final后面必须紧跟着初始化。
• 单例模式创建对象的步骤:

1. 私有化构造函数
2. 类内部创建对象
3. 提供一个共有静态方法，对外返回实例对象。

饿汉式 - 静态变量

• 静态的作用是在类加载的时候直接进行处理。
• 静态方法使用的变量必须是静态变量。

class Singeton{
   
	private Singeton(){
   
		//......
	}
	private final static Singeton instance