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

川长思鸟来 2022-05-09 14:20 233阅读 0赞

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

### 单一职责原则 ###

*  官方定义：
    
     *  就一个类(接口、结构体、方法等等)而言，有且仅有一个引起它变化的原因。
 *  个人理解：
    
     *  通俗的来讲做一件事就是专注做一件事，不可以三心二意。任务对象只是专注于一项职责，不去承担太多的责任。当任务对象的职责发生变化时，不会对其他的对象产生影响。
 *  遵循单一职责原的优点：
    
     *  可以大大降低耦合度。
     *  降低类的复杂度。
     *  提高类的可读性。
     *  降低因变更而引起的风险。
     *  提高类的复用性和可维护性。
 *  单一职责应用：
    
     *  背景：有一个类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

[70]: /images/20220506/00e86f1fa0d74db7b049ff1e4454f661.png