java七大设计原则(下)

接口隔离原则

接口隔离原则（Interface Segregation Principle, ISP）是指用多个专门的接口，而不使用单一的 总接口，客户端不应该依赖它不需要的接口。
这个原则指导我们在设计接口时应当注意一下几点：
1、一个类对一类的依赖应该建立在最小的接口之上。
2、建立单一接口，不要建立庞大臃肿的接口。
3、尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。
接口隔离原则符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性 和可维护性。
我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括以后有可能发生变更 的地方还要做一些预判。所以，对于抽象，对业务模型的理解是非常重要的。
下面我们来看一段代码， 写一个动物行为的抽象： IAnimal 接口：

 public interface IAnimal { 
	 void eat(); 
	 void fly(); 
	 void swim(); 
 }

Bird 类实现：

  public class Bird implements IAnimal {
	   @Override 
	   public void eat() {} 
	   @Override 
	   public void fly() {} 
	   @Override 
	   public void swim() {} 
   }

Dog 类实现：

public class Dog implements IAnimal { 
	@Override 
	public void eat() {} 
	@Override 
	public void fly() {} 
	@Override 
	public void swim() {} 
}

可以看出，Bird 的 swim()方法可能只能空着，Dog 的 fly()方法显然不可能的。这时候，我们针对 不同动物行为来设计不同的接口，分别设计 IEatAnimal，IFlyAnimal 和 ISwimAnimal 接口，来看代码：
IEatAnimal 接口：

public interface IEatAnimal { 
	void eat(); 
}

IFlyAnimal 接口：

public interface IFlyAnimal { 
	void fly(); 
}

ISwimAnimal 接口：

  public interface ISwimAnimal { 
	  void swim(); 
  }

Dog 只实现 IEatAnimal 和 ISwimAnimal 接口：

 public class Dog implements ISwimAnimal,IEatAnimal { 
	@Override 
	public void eat() {} 
	@Override
	public void swim() {} 
 }

来看下两种类图的对比，还是非常清晰明了的：

迪米特法则

迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则（Least Knowledge Principle,LKP），尽量降低类与类之间的耦合。
迪米特原则主要强调只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类, 而出现在方法体内部的类不属于朋友类。
现在来设计一个权限系统，TeamLeader需要查看目前发布到线上的课程数量。这时候，TeamLeader 要找到员工 Employee 去进行统计，Employee 再把统计结果告诉 TeamLeader。接下来我们还是来看 代码：
Course 类：

 public class Course { }

Employee 类：

public class Employee{ 
	public void checkNumberOfCourses(List<Course> courseList){ 
	System.out.println("目前已发布的课程数量是：" + courseList.size()); } 
}

TeamLeader 类：

 public class TeamLeader{ 
	public void commandCheckNumber(Employee employee){ 			
		List<Course> courseList = new ArrayList<Course(); 
		for (int i= 0; i < 20 ;i ++){ 
		courseList.add(new Course()); 
		}
		employee.checkNumberOfCourses(courseList); 
	} 
 }

测试代码：

public static void main(String[] args) { 
	TeamLeader teamLeader = new TeamLeader(); 
	Employee employee = new Employee(); 	
	teamLeader.commandCheckNumber(employee); 
}

写到这里，其实功能已经都已经实现，代码看上去也没什么问题。根据迪米特原则，TeamLeader 只想要结果，不需要跟 Course 产生直接的交流。而 Employee 统计需要引用 Course 对象。TeamLeader 和 Course 并不是朋友，从下面的类图就可以看出来：

下面来对代码进行改造：
Employee 类：

public class Employee { 
	public void checkNumberOfCourses(){ 
		List<Course> courseList = new ArrayList<Course(); 
		for (int i= 0; i < 20 ;i ++){ 
			courseList.add(new Course()); 
		}
		System.out.println("目前已发布的课程是："+courseList.size()); 
	} 
}

TeamLeader 类：

public class TeamLeader { 
	public void commandCheckNumber(Employee employee){ 				
		employee.checkNumberOfCourses(); 
  	} 
}

再来看下面的类图，Course 和 TeamLeader 已经没有关联了。

学习软件设计原则，千万不能形成强迫症。碰到业务复杂的场景，我们需要随机应变。

里氏替换原则

里氏替换原则（Liskov Substitution Principle,LSP）是指如果对每一个类型为 T1 的对象 o1,都有 类型为 T2 的对象 o2,使得以 T1 定义的所有程序 P 在所有的对象 o1 都替换成 o2 时，程序 P 的行为没 有发生变化，那么类型 T2 是类型 T1 的子类型。

定义看上去还是比较抽象，我们重新理解一下，可以理解为一个软件实体如果适用一个父类的话， 那一定是适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类 对象，而程序逻辑不变。根据这个理解，我们总结一下：
引申含义：子类可以扩展父类的功能，但不能改变父类原有的功能。
1、子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
2、子类中可以增加自己特有的方法。
3、当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入 参数更宽松。
4、当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输 出/返回值）要比父类更严格或相等。
在前面讲开闭原则的时候埋下了一个伏笔，我们记得在获取折后时重写覆盖了父类的 getPrice()方 法，增加了一个获取源码的方法 getOriginPrice()，显然就违背了里氏替换原则。
我们修改一下代码， 不应该覆盖 getPrice()方法，增加 getDiscountPrice()方法：

public class JavaDiscountCourse extends JavaCourse { 	
			
	public JavaDiscountCourse(Integer id, String name, Double price) {
		super(id, name, price); 
	}
	public Double getDiscountPrice(){ 
		return super.getPrice() * 0.61;
	}
}

使用里氏替换原则有以下优点：
1、约束继承泛滥，开闭原则的一种体现。
2、加强程序的健壮性，同时变更时也可以做到非常好的兼容性，提高程序的维护性、扩展性。降低 需求变更时引入的风险。
现在来描述一个经典的业务场景，用正方形、矩形和四边形的关系说明里氏替换原则，我们都知道 正方形是一个特殊的长方形，那么就可以创建一个长方形父类 Rectangle 类：

public class Rectangle { 
	private long height; 
	private long width; 
	public long getHeight() { return height; }
	public void setHeight(long height) { this.height = height;}
	public long getWidth() { return width; }
	public void setWidth(long width) { this.width = width; } 
	}

创建正方形 Square 类继承长方形：

public class Square extends Rectangle { 
private long length; 
public long getLength() { return length; }
public void setLength(long length) { this.length = length; }
@Override
public long getHeight() { return getLength(); }
@Override
public void setHeight(long height) { setLength(height);}
@Override 
public long getWidth() { return getLength(); }
@Override 
public void setWidth(long width) { setLength(width); } } 

在测试类中创建 resize()方法，根据逻辑长方形的宽应该大于等于高，我们让高一直自增，知道高 等于宽变成正方形：

 public static void resize(Rectangle rectangle){ 
 	while (rectangle.getWidth() >= rectangle.getHeight(){ 		
 		rectangle.setHeight(rectangle.getHeight() + 1); 
 		System.out.println("Width:" +rectangle.getWidth() 
 		+",Height:" + rectangle.getHeight()); 
 	}

	System.out.println("Resize End,Width:" 
	+rectangle.getWidth() +",Height:" + 
	rectangle.getHeight()); 
 }

测试代码：

public static void main(String[] args) { 
	Rectangle rectangle = new Rectangle(); 		
	rectangle.setWidth(20); 
	rectangle.setHeight(10); 
	resize(rectangle); 
}

运行结果： 发现高比宽还大了，在长方形中是一种非常正常的情况。现在我们再来看下面的代码，把长方形 Rectangle 替换成它的子类正方形 Square，修改测试代码：

  public static void main(String[] args) { 
	  Square square = new Square(); 
	  square.setLength(10); 
	  resize(square); 
  }

这时候我们运行的时候就出现了死循环，违背了里氏替换原则，将父类替换为子类后，程序运行结 果没有达到预期。因此，我们的代码设计是存在一定风险的。里氏替换原则只存在父类与子类之间，约束继承泛滥。我们再来创建一个基于长方形与正方形共同的抽象四边形 Quadrangle 接口：

 public interface QuadRangle { 
	long getWidth(); 
	long getHeight(); 
} 

修改长方形 Rectangle 类：

 public class Rectangle implements QuadRangle { 
	 private long height; 
	 private long width; 
	 public long getHeight() { return height; }
	 public void setHeight(long height) { this.height = height; }
	 public long getWidth() { return width; }
	 public void setWidth(long width) { this.width = width; } 
}

修改正方形类 Square 类：

public class Square implements QuadRangle { 
	private long length; 
	public long getLength() { return length; }
	public void setLength(long length) { this.length = length; }
	public long getWidth() { return length; }
	public long getHeight() { return length; } 
} 

此时，如果我们把 resize()方法的参数换成四边形 Quadrangle 类，方法内部就会报错。因为正方 形 Square 已经没有了 setWidth()和 setHeight()方法了。因此，为了约束继承泛滥，resize()的方法参 数只能用 Rectangle 长方形。当然，我们在后面的设计模式课程中还会继续深入讲解。

#合成复用原则
合成复用原则（Composite/Aggregate Reuse Principle,CARP）是指尽量使用对象组合(has-a)/ 聚合(contanis-a)，而不是继承关系达到软件复用的目的。
可以使系统更加灵活，降低类与类之间的耦 合度，一个类的变化对其他类造成的影响相对较少。 继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。
组合/聚合也称之为黑箱复用，对类 以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计，其实也都需要遵循 OOP 模型。还是以数据库操作为例，先来创建 DBConnection 类：

 public class DBConnection { 
	 public String getConnection(){ return "MySQL 数据库连接"; }
 }

创建 ProductDao 类：

 public class ProductDao{ 
	private DBConnection dbConnection; 
 	public void setDbConnection(DBConnection dbConnection{
 		this.dbConnection = dbConnection;
 	}
 	public void addProduct(){ String conn = dbConnection.getConnection(); 		
 	System.out.println("使用"+conn+"增加产品"); } 
 }

这就是一种非常典型的合成复用原则应用场景。但是，目前的设计来说，DBConnection 还不是一 种抽象，不便于系统扩展。目前的系统支持 MySQL 数据库连接，假设业务发生变化，数据库操作层要 支持 Oracle 数据库。当然，我们可以在 DBConnection 中增加对 Oracle 数据库支持的方法。但是违 背了开闭原则。其实，我们可以不必修改 Dao 的代码，将 DBConnection 修改为 abstract，来看代码：

 public abstract class DBConnection { 
 	public abstract StringgetConnection(); 
 }

然后，将 MySQL 的逻辑抽离：

 
 public class MySQLConnection extends DBConnection { 
	 @Override 
	 public String getConnection() { return "MySQL 数据库连接"; } 
 } 

再创建 Oracle 支持的逻辑：

 public class OracleConnection extends DBConnection { 
	 @Override 
	 public String getConnection() { return "Oracle 数据库连接"; } 
 }

具体选择交给应用层，来看一下类图：

设计原则总结 学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原 则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的 是一种平衡取舍，帮助我们设计出更加优雅的代码结构。