设计模式的七大原则与分类总览

设计模式的目的：

1. 提高代码的重用性，即 相同功能的代码不用多次编写。
2. 提高可读性，即 便于其他程序员的阅读和理解。
3. 提高可拓展性，即 便于增加行的功能，可维护。
4. 提高可靠性，即 增加新功能后，对原来的功能没有影响。
5. 使程序呈现 高内聚，低耦合的特性。

设计原则的核心思想：

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

1. 单一职责

解释：一个类应该只负责一项职责。分为 [ 类级别] 上遵守单一职责原则，[ 方法上] 遵守单一职责原则。

通常情况下，我们应当遵守类级别上的单一职责原则，只有逻辑足够简单，类中方法数量足够少的时候，可以在方法级别保持单一职责。

2. 接口隔离原则

解释：一个类对另一个类的依赖，应该建立在最小的接口上。

例子：
A类通过Interface1依赖于B类。【 仅需要m1(),m2(),m3()方法 】
C类通过Interface1依赖于D类。【 仅需要m1(),m4(),m5()方法 】
–>>–

// 接 口 1
interface Interface1 { void operation1();}
// 接 口 2
interface Interface2 { 
	void  operation2();
	void operation3();
}
// 接 口 3
interface Interface3 {
 	void operation4();
	void operation5();
}
class B implements Interface1, Interface2 {
	public void operation1() {
		System.out.println("B 实现了 operation1");}
	public void operation2() {
		System.out.println("B 实现了 operation2");}
	public void operation3() {
		System.out.println("B 实现了 operation3");}	
}

class A { // A 类通过接口 Interface1,Interface2 依赖(使用) B 类，但是只会用到 1,2,3 方法
	public void depend1(Interface1 i) {   i.operation1();  }
	public void depend2(Interface2 i) {   i.operation2();  }
	public void depend3(Interface2 i) {   i.operation3();  }
}
//同理可以写出C,D的代码，class C{} class D implements Interface1,Interface3{}

//主方法
public static void main(String[] args) {
	A a = new A();
	a.depend1(new B()); // A 类通过接口去依赖 B 类
	a.depend2(new B());
	a.depend3(new B());

	C c = new C();
	c.depend1(new D()); // C 类通过接口去依赖(使用)D 类
	c.depend4(new D());
	c.depend5(new D());
}

3.依赖倒转原则

解释：
	1. 高层模块不应该依赖于底层模块，二者都应该依赖其抽象。
	2. 抽象不应该依赖细节，细节应该依赖抽象。
	3. 依赖倒转的中心思想：面向接口编程。

相对于细节的多变性，抽象的东西稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多，在Java中，抽象指的是接口或抽象类，细节就是具体的实现类------在Java中，高层往往是接口或抽象类。

例子：person类可以接受多种来源的信息。便于拓展。
//定义接口
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";
	}
}


class Person {
	//这里我们是对接口的依赖
	public void receive(IReceiver receiver ) { 
		System.out.println(receiver.getInfo());
	}
}


public static void main(String[] args) {
	//客户端可以接受多钟类型的信息
	Person p = new Person(); 
	 p.receive(new Email());
	 p.receive(new WeiXin());
}

4.里氏替换原则

解释：简单而言，即 子类中尽量不要重写父类的方法。 继承实际上让两个类的耦合性增强了，在适当的情况下，
     可以通过聚合，组合，依赖来解决问题。
     or 原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖，聚合，组合等关系代替.

5.开闭原则

解释：一个软件实体，比如类，模块和函数应该对扩展开放【 对提供方 】，对修改关闭【 对使用方 】。
 	我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码.
	用抽象构建框架，用实体拓展细节。

例子：一个类绘制各种图形。
/**
未满足开闭原则OpenClosePrincle
 */
public static void main(String[] args) {
	GraphicEditor graphicEditor = new GraphicEditor();
		graphicEditor.drawShape(new Rectangle()); 
		graphicEditor.drawShape(new Circle()); 		
		graphicEditor.drawShape(new Triangle());
}
//这是一个用于绘图的类 [使用方] 
class GraphicEditor {
//接收 Shape 对象，然后根据 type，来绘制不同的图形
	public void drawShape(Shape s) {
		if (s.m_type == 1) drawRectangle(s);
			else if (s.m_type == 2) drawCircle(s);//如果增加新的图形进来时，需要在这里进行修改，不满足修改关闭原则。
}
//绘制矩形
public void drawRectangle(Shape r) { System.out.println(" 绘制矩形 ");}
//绘制圆形
public void drawCircle(Shape r) {System.out.println(" 绘制圆形 ");}

//shape 类，基类
class Shape {
	int m_type;
}

class Rectangle extends Shape { 
	Rectangle() {
		super.m_type = 1;
	}
}

class Circle extends Shape { 
	Circle() {
		super.m_type = 2;
	}
}


/**
	满足OCP原则的情况：
   	创建 Shape 类做成抽象类，并提供一个抽象的 draw 方法，让子类去实现即可，这样我们有新的图形种类时，只需要让新的图形类继承 Shape，并实现 draw 方法即可，使用方的代码就不需要修 
*/
public static void main(String[] args) {
	//使用看看存在的问题
	GraphicEditor graphicEditor = new GraphicEditor(); 
	graphicEditor.drawShape(new Rectangle()); 
	graphicEditor.drawShape(new OtherGraphic());
}

//这是一个用于绘图的类 [使用方] 
class GraphicEditor {
	//接收 Shape 对象，调用 draw 方法
	public void drawShape(Shape s) {
		 s.draw();
	}
}

//Shape 类，基类
abstract class Shape {
	int m_type;
	public abstract void draw();//抽象方法
}


class Rectangle extends Shape { 
	Rectangle() {
		super.m_type = 1;
	}
	@Override
	public void draw() {
		System.out.println(" 绘制矩形 ");
	}
}


class Circle extends Shape { 
	Circle() {
		super.m_type = 2;
	}
	@Override
	public void draw() {
		System.out.println(" 绘制圆形 ");
	}
}

//新增一个图形
class OtherGraphic extends Shape { 
	OtherGraphic() {
		super.m_type = 4;
	}
	@Override
	public void draw() {
		System.out.println(" 绘制其它图形 ");
	}
}

6.迪米特原则

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

7.合成复用原则

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

UML简单知识：

类与接口的 依赖、泛化、实现、关联、组合、聚合的关系。
1. 依赖，表示使用 【只要在类中用到了对方，那么它们之间就存在依赖关系。】
2. 泛化，继承关系 【泛化关系实际上就是继承关系，它是依赖关系的特例.Generalizaion】
3. 实现，依赖关系的特例。
4. 关联，一对多，多对一。
5. 聚合，【整体与部分的关系，可以分开。为关联关系的特例 】
6.组合， 【整体与部分的关系，但是不能分开，人的头部！】。