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

在程序设计中,我们通常要遵循以下六大原则:
JAVA设计模式之六大设计原则_第1张图片

单一职责原则

  • 官方定义:
    • 就一个类(接口、结构体、方法等等)而言,有且仅有一个引起它变化的原因。
  • 个人理解:
    • 通俗的来讲做一件事就是专注做一件事,不可以三心二意。任务对象只是专注于一项职责,不去承担太多的责任。当任务对象的职责发生变化时,不会对其他的对象产生影响。
  • 遵循单一职责原的优点:
    • 可以大大降低耦合度。
    • 降低类的复杂度。
    • 提高类的可读性。
    • 降低因变更而引起的风险。
    • 提高类的复用性和可维护性。
  • 单一职责应用:
    • 背景:有一个类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 getAllEmployee(){
		List list = new ArrayList();
		for(int i=0; i<100; i++){
			SubEmployee emp = new SubEmployee();
			//为分公司人员按顺序分配一个ID
			emp.setId("分公司"+i);
			list.add(emp);
		}
		return list;
	}
}
 
class CompanyManager{
 
	public List getAllEmployee(){
		List list = new ArrayList();
		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 list1 = sub.getAllEmployee();
		for(SubEmployee e:list1){
			System.out.println(e.getId());
		}
 
		List 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 getAllEmployee(){
		List list = new ArrayList();
		for(int i=0; i<100; i++){
			SubEmployee emp = new SubEmployee();
			//为分公司人员按顺序分配一个ID
			emp.setId("分公司"+i);
			list.add(emp);
		}
		return list;
	}
	public void printEmployee(){
		List list = this.getAllEmployee();
		for(SubEmployee e:list){
			System.out.println(e.getId());
		}
	}
}
 
class CompanyManager{
	public List getAllEmployee(){
		List list = new ArrayList();
		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 list2 = this.getAllEmployee();
		for(Employee e:list2){
			System.out.println(e.getId());
		}
	}
}

开闭原则

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

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

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

你可能感兴趣的:(设计模式)