设计模式开篇

设计模式的目的

• 代码重用性 （相同的代码，不用多次编写）
• 可读性 （代码规范）
• 可扩展性（增加新功能点，比较方便）
• 可靠性 （增加新功能，对旧的功能没有影响）
• 程序高内聚，低耦合

设计模式的七大原则

• 单一职责原则
  每个类只完成一件事情（原子的，不能再被拆分的）
  如果是方法比较少，可以将单一职责 推后到方法上
• 接口隔离原则
  一个类对另一个类的依赖应该建立在最小的接口上
  比如一个接口A 有三个方法

@interface A {
	void method1();
	void method2();
	void method3();
}

B类依赖了A类，是为了实现方法method1() 和 method()2
C类依赖了A类，是为了实现方法method3()
为了进行方法之间的隔离 ，就应该根据方法的被调用组合情况，拆分接口

@interface A1 {
	void method1();
	void method2();
}

@interface A2 {
	void method3();
}

• 依赖倒转原则
  因为类，接口 可以向上自动转化，所以定义参数，或者成员变量都是定义成对应抽象类，或者是接口，在具体实现的时候才传入对应的 子类或者实现类
  比如B类依赖了A类，那么成员方法，或者是参数列表 应该定义为A的抽象类 或者A的接口

public class B {
	//AbstractA 是A的抽象类
	private AbstractA a;
	public B (AbstractA a){
		this.a = a;
	}
}
//具体的实现是
   new B (new A()); //这样我们就可以变动的传入AbstractA的一系列子类

• 里氏替换原则

  • 子类尽量不要重写父类的方法
  • 少用继承，多用聚合，组合，依赖 （因为一个父类的变动，可能会影响到子类）

• 开闭原则

  • 对 提供方 扩展开放
  • 对 接受方 修改关闭
    就比如上面的B类，就是A类，采用依赖他的父类AbstractA，当我们需要用到其他的A类时，不需要改动B接受的AbstractA ，只要让提供的类继承AbstractA传入就可以了，实现了对提供扩展开放，对接受修改关闭

例如

public class B {
	//AbstractA 是A的抽象类
	private AbstractA a;
	public B (AbstractA a){
		this.a = a;
	}
}
//我们要传入不同A类去构建B
A1 extends AbstractA {}
A2 extends AbstractA {}
new B (new A1());
new B (new A2());

• 迪米特法则

  • 最少知道原则，一个类对自己的依赖的类知道的越少越好
  • 每个对象都可能会与其他对象有耦合关系，只要两个对象存在耦合关系，我们就称之为朋友关系
  • 直接朋友关系 ： 成员变量，参数列表，返回值
  • 不是直接朋友关系的类，不要以局部变量的方式出现在类的内部

• 合成复用原则

  • 尽量用组合/聚合方式，少用继承

UML图

• 用于描述系统中的类本身的组成 和 其他类之间的各种静态关系

• 类图 - 依赖关系

  • 只要在类种用到了对方，就产生了依赖关系，没有对方，编译都通过不了
    
    

• 类图 - 泛化关系

  • 就是继承关系，是依赖关系的特例
    
    

• 类图 - 实现关系

  • 就是A实现了B接口，也是依赖关系的特例
    

• 类图 - 关联关系

  • 比如A注入成员变量B ，B注入成员变量 A
    

• 类图 - 聚合关系

  • 整体和部分的关系，整体可和部分拆分
    
    

• 类图 - 组合关系

  • 也是整体和部分的关系，但是整体不可以和部分拆分