JAVA设计模式之六大设计原则

在程序设计中，我们通常要遵循以下六大原则：
在这里插入图片描述

单一职责原则

官方定义：
- 就一个类(接口、结构体、方法等等)而言，有且仅有一个引起它变化的原因。
个人理解：
- 通俗的来讲做一件事就是专注做一件事，不可以三心二意。任务对象只是专注于一项职责，不去承担太多的责任。当任务对象的职责发生变化时，不会对其他的对象产生影响。
遵循单一职责原的优点：
- 可以大大降低耦合度。
- 降低类的复杂度。
- 提高类的可读性。
- 降低因变更而引起的风险。
- 提高类的复用性和可维护性。
单一职责应用：
- 背景：有一个类A，他需要负责T1和T2。但是当职责T1因为需求而改变类A的时候，就会对职责T2造成影响，导致T2不能正常工作。
- 解决办法：针对职责T1创建类A，针对职责T2创建类B。这样就可以达到当修改类A时不会对职责T2造成影响，当修改类B时不会对职责T1造成影响。

里氏替换原则

官方定义：
- 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
个人理解：
- 继承必须确保父类所拥有的性质在子类中仍然成立。
- 或者说子类可以扩展父类的功能，但不能改变父类原有的功能。
- 子类中可以增加自己特有的方法。
- 子类的方法实现父类的抽象方法时，方法的返回值要比父类的返回值更加严谨。
继承是面向对象的三大特性之一，在程序设计方面带来了很大的便利性，但是同时也存在一些不好的地方：增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
经典案例之正方形不是长方形：
- 在大众的认知范围内长方形的长和宽是不相等的，正方形的长和宽是相等的，正方形属于特殊的长方形。
- 先定义一个长方形类

public class Rectangle {

	private int width;
	private int height;

	public int getWidth() {
		return width;
	}

	public void setWidth(int width) {
		this.width = width;
	}

	public int getHeight() {
		return height;
	}

	public void setHeight(int height) {
		this.height = height;
	}

	public Rectangle(int width, int height) {
		this.width = width;
		this.height = height;
	}

	public int area() {
		return width * height;
	}

}

再定义一个正方形类，继承自长方形类

public class Square extends Rectangle {

	private int width;

	public int getWidth() {
		return width;
	}

	public void setWidth(int width) {
		this.width = width;
	}

	public Square(int width, int height) {
		super(width, height);
	}
	
	/*
	 * 重写 area()
	 * 
	 * @see design.Rectangle#area()
	 */
	public int area() {
		return width * width;
	}
}

输出结果

public class Tester {

	public static void main(String[] args) {
		Rectangle rectangle = new Rectangle(10, 20);
		System.out.println("面积：" + rectangle.area());
	}
	// 输出结果为面积：200
}

public class Tester {

	public static void main(String[] args) {
		Square rectangle = new Square(10, 20);
		System.out.println("面积：" + rectangle.area());
	}
	// 输出结果为面积：0
}

分析：为什么当Rectangle替换为Square之后，面积的结果出错了呢？因为在Square类里重写了area()方法，很明显违背了里氏替换原则，改变了父类的原有功能，所以导致输出结果不对。

依赖倒置原则

所谓依赖倒置原则（Dependence Inversion Principle）就是要依赖于抽象，不要依赖于具体。实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现，如果说开闭原则是面向对象设计的目标的话，那么依赖倒置原则就是面向对象设计的主要手段。

官方定义：
- 高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
个人理解：
- 依赖倒置原则的核心思想就是让我们面向接口编程。
- 抽象是面向对象的三大特性之一，相对于细节的多变性，抽象的东西要稳定的多。在Java中抽象指的就是接口和抽象类，接口和抽象类只是定义好规范和规则，而不去关注任何实现，具体的实现都交给实现类去关注。
应用场景是这样的，母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了（copy自网上）。


class Book{
	public String getContent(){
		return "很久很久以前有一个阿拉伯的故事……";
	}
}
 
class Mother{
	public void narrate(Book book){
		System.out.println("妈妈开始讲故事");
		System.out.println(book.getContent());
	}
}
 
public class Client{
	public static void main(String[] args){
		Mother mother = new Mother();
		mother.narrate(new Book());
	}
}

运行结果：

妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……

但是现在问题来了，当我修改了Book类，由原先的读书变成读报纸，这个时候Mother类就不会了，那么这个问题怎么解决呢？

两种方法解决：
①第一种：直接去修改Mother类，将Book类直接替换成Newspaper类。这样是可以解决一时的问题，但是将来我不仅仅是读书，而且还要读邮件等等呢，Mother和Book之间的耦合性太高了，所以不是一个好的办法。
②第二种：我们引入一个抽象的接口IReader。

interface IReader{
	public String getContent();
}

Mother类与接口IReader发生依赖关系，而Book和Newspaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改为：

class Newspaper implements IReader {
	public String getContent(){
		return "林书豪17+9助尼克斯击败老鹰……";
	}
}
class Book implements IReader{
	public String getContent(){
		return "很久很久以前有一个阿拉伯的故事……";
	}
}
 
class Mother{
	public void narrate(IReader reader){
		System.out.println("妈妈开始讲故事");
		System.out.println(reader.getContent());
	}
}
 
public class Client{
	public static void main(String[] args){
		Mother mother = new Mother();
		mother.narrate(new Book());
		mother.narrate(new Newspaper());
	}
}

运行结果：

妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
妈妈开始讲故事
林书豪17+9助尼克斯击败老鹰……

这样修改后，无论以后怎样扩展Client类，都不需要再修改Mother类了。

最佳实践
- 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。
- 变量的显示类型尽量是接口或者是抽象类。
- 任何类都不应该从具体类派生。
- 尽量不要覆写基类的方法。
- 结合里氏替换原则使用。

接口隔离原则

官方定义：
- 客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
个人理解：
- 单从字面上理解：使用多个隔离的接口，而不是使用单一的接口。
- 接口隔离原则的本意是降低类之间的耦合性。在大型的软件设计中，为了方便维护和扩展，降低类之间的依赖和耦合是很必要的。
- 建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。
举一反三
- 一开始我自己觉的接口隔离原则跟之前的单一职责原则很相似，其实不然。
- 其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。
- 其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建。
最佳实践：
- 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
- 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
- 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

迪米特法则

官方定义：
- 一个对象应该对其他对象保持最少的了解。
个人理解：
- 一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
- 也就是说一个软件实体应当尽可能少的与其他实体发生相互作用。
- 当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，就是说可扩展性很好。
举一个例子：有一个集团公司，下属单位有分公司和直属部门，现在要求打印出所有下属单位的员工ID。先来看一下违反迪米特法则的设计。

//总公司员工
class Employee{
	private String id;
	public void setId(String id){
		this.id = id;
	}
	public String getId(){
		return id;
	}
}
 
//分公司员工
class SubEmployee{
	private String id;
	public void setId(String id){
		this.id = id;
	}
	public String getId(){
		return id;
	}
}
 
class SubCompanyManager{
	public List<SubEmployee> getAllEmployee(){
		List<SubEmployee> list = new ArrayList<SubEmployee>();
		for(int i=0; i<100; i++){
			SubEmployee emp = new SubEmployee();
			//为分公司人员按顺序分配一个ID
			emp.setId("分公司"+i);
			list.add(emp);
		}
		return list;
	}
}
 
class CompanyManager{
 
	public List<Employee> getAllEmployee(){
		List<Employee> list = new ArrayList<Employee>();
		for(int i=0; i<30; i++){
			Employee emp = new Employee();
			//为总公司人员按顺序分配一个ID
			emp.setId("总公司"+i);
			list.add(emp);
		}
		return list;
	}
	
	public void printAllEmployee(SubCompanyManager sub){
		List<SubEmployee> list1 = sub.getAllEmployee();
		for(SubEmployee e:list1){
			System.out.println(e.getId());
		}
 
		List<Employee> list2 = this.getAllEmployee();
		for(Employee e:list2){
			System.out.println(e.getId());
		}
	}
}
 
public class Client{
	public static void main(String[] args){
		CompanyManager e = new CompanyManager();
		e.printAllEmployee(new SubCompanyManager());
	}
}

现在这个设计的主要问题出在CompanyManager中，根据迪米特法则，只与直接的朋友发生通信，而SubEmployee类并不是CompanyManager类的直接朋友（以局部变量出现的耦合不属于直接朋友），从逻辑上讲总公司只与他的分公司耦合就行了，与分公司的员工并没有任何联系，这样设计显然是增加了不必要的耦合。按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下:

class SubCompanyManager{
	public List<SubEmployee> getAllEmployee(){
		List<SubEmployee> list = new ArrayList<SubEmployee>();
		for(int i=0; i<100; i++){
			SubEmployee emp = new SubEmployee();
			//为分公司人员按顺序分配一个ID
			emp.setId("分公司"+i);
			list.add(emp);
		}
		return list;
	}
	public void printEmployee(){
		List<SubEmployee> list = this.getAllEmployee();
		for(SubEmployee e:list){
			System.out.println(e.getId());
		}
	}
}
 
class CompanyManager{
	public List<Employee> getAllEmployee(){
		List<Employee> list = new ArrayList<Employee>();
		for(int i=0; i<30; i++){
			Employee emp = new Employee();
			//为总公司人员按顺序分配一个ID
			emp.setId("总公司"+i);
			list.add(emp);
		}
		return list;
	}
	
	public void printAllEmployee(SubCompanyManager sub){
		sub.printEmployee();
		List<Employee> list2 = this.getAllEmployee();
		for(Employee e:list2){
			System.out.println(e.getId());
		}
	}
}

开闭原则

官方定义：
- 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
个人理解：
- 如果修改或者添加一个功能，应该是通过扩展原来的代码，而不是通过修改原来的代码。
应用场景：略。

总的来说，程序设计尽量的贴近软件编程的总的原则：高内聚，低耦合。

参考资料：https://blog.csdn.net/column/details/pattern.html