学习笔记:设计原则

单一职责原则(SRP)

单一职责原则的英文名称是Single Responsibility Principle

定义

一个类,应当只有一个引起它变化的原因;即一个类应该只有一个职责。

就一个类而言,应该只专注于做一件事和仅有一个硬气变化的原因,这就是所谓的单一职责原则。

所谓“职责”,就是对象能够承担的责任,并以某种行为来执行。
对象的职责总是要提供给其他对象进行调用的,从而形成对象与对象的协作,由此产生对象之间的依赖关系。类职责越小,则对象之间的依赖关系就越少,耦合度就减弱,受其他对象的约束与牵制就越少,从而保证了系统的可扩展性。因此,在单一职责原则中,也可以把“职责”定义为“变化的原因”。如果存在多个动机去改变一个类,那么这个类就具有多于一个的职责。

单一职责原则并不是极端地要求我们只能为类定义一个职责,而是利用极端的表述方式重点强调,在定义对象职责时,必须考虑职责与对象之间的所属关系。职责必须恰如其分地表现对象的行为,而不至于破坏和谐与平衡的美感,甚至格格不入。换言之,该原则描述的单一职责指的是公开在外的与该对象紧密相关的一组职责。

单一职责的优点:

  • 降低类的复杂性
  • 提高类的可读性
  • 提高代码的可维护性和复用性
  • 降低因变更引起的风险

例子:以用户管理为例

在这里插入图片描述
在业务逻辑层定义类UserManager,在数据访问层定义类UserDao,在实体对象层定义类User,每个类具有不同的职责和功能。

里氏替换原则(LSP)

里氏替换原则的英文名称是:Liskov Substitution Principle

定义

里氏替换原则的定义有以下两种:

第一种定义:
如果对一个类型为S的对象o1,都有类型为T的对象o2,使得以S为定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型T是类型S的子类型。

第二种定义:所有引用父类的地方必须能透明地使用其子类对象。清晰明确地说明只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者可能根本就不需要知道父类还是子类;但是反过来则不可以,有子类的地方,父类未必能适应。

里氏替换原则为良好的继承定义了一个规范,它包含4层含义:

  • 子类必须完全实现父类的方法;
  • 子类可以有自己的个性;(子类可以增加方法)
  • 覆盖或实现父类的方法时输入参数可以被放大;
  • 覆盖或实现父类地方法时输出结果可以被缩小。

例子

在这里插入图片描述
Animal是一个表示动物地抽象类,只要动物就都能动,因此提供一个抽象的move()方法;Horse和Bird都是Animal的子类。

Animal.java

//抽象类
public abstract class Animal{
//抽象方法
	public abstract void move();
}

Horse.java

public class Horse extends Animal{
	public void move(){
		system.out.println("马儿跑");
	}
}

Bird.java

public class Bird extends Animal{
	public void move(){
		system.out.println("鸟儿飞");
	}
}

在设计模式中体现里氏替换原则的有如下几个模式:

  • 策略模式
  • 组合模式
  • 代理模式

补充:
Compiler-enforced rules in Java(static type checking)
Java中编译器强制的规则(静态类型检查)

  • 子类可以增加方法,但不可删
  • 子类需要实现抽象类型中的所有未实现方法
  • 子类中重写的方法必须有相同或子类型的返回值或者符号co-variance的参数
  • 子类中重写的方法必须使用同样类型的参数或者contra-variance的参数
  • 子类中重写的方法不能抛出额外的异常

依赖倒置原则(DIP)

依赖倒置原则英文名称是:Dependence Inversion Principle

定义

具有三层含义:

  • 高层模块不应该依赖底层模块,两者都依赖其抽象;
  • 抽象不依赖细节;
  • 细节应该依赖于抽象。

依赖倒置原则在Java语言中的表现是:

  • 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生;
  • 接口或抽象类不依赖于实现类;
  • 实现类依赖于接口或抽象类。

依赖倒置原则更加精确的定义就是“面向接口编程”——OOD(Object-Oriented Design)的精髓之一。依赖倒置原则可以减少类之间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。

例子

在这里插入图片描述
在现实生活中,司机只要会开车,就可以开奔驰,也可以开宝马车。因此司机不依赖于奔驰车或宝马车,而是通过上图所示的接口,使他们之间的依赖关系倒置。

IDriver.java

//司机接口
public interface IDriver{
	//司机都会驾驶汽车
	public void drive(ICar car);//在drive中传入ICar接口,实现IDriver和ICar抽象之间的依赖关系
}

Driver.java

//司机类
public class Driver implements IDriver{
	//司机的主要职责是驾驶
	public void driver(ICar car){
	car.run();
	}
}

Icar.java

//汽车接口
public interface ICar{
	//汽车都能跑
	public void run();
}

Benz.java

//奔驰车
public class Benz implements ICar{
	public void run(){
		system.out.println("奔驰汽车在行驶···");
	}
}

BMW.java

public class BMW implements ICar{
	public void run(){
		system.out.println("宝马汽车在行驶···");
	}
}

总结:
依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,互不影响,实现模块间的松耦合。在项目中使用这个原则只要遵循以下几个规则:

  • 每个类尽量都具有接口或抽象类,或者抽象类和接口两者都具备。这是依赖倒置的基本要求,接口和抽象类都是抽象的,有了抽象才可能有依赖倒置。
  • 变量的表面类型尽量是接口或者是抽象类;
  • 任何类都不应该从具体类派生;
  • 尽量不要重写父类的方法。如果父类是一个抽象类,而且这个方法已经实现了,子类尽量不要重写。类之间依赖的是抽象,重写了非抽象方法,对依赖的稳定性会产生一定的影响;
  • 结合里氏替换原则使用。里氏替换原则指出父类出现的地方子类就可以出现,结 合依赖倒置原则可以得出一个通俗的规则:接口负责定义抽象方法,并且声明与 其他对象的依赖关系,抽象类负责公共构造部分的实现,实现类准确地实现业务 逻辑,同时在适当的时候对父类进行细化。

接口隔离原则(ISP)

接口隔离原则的英文名称是:Interface Segregation Principle

定义

首先明确“接口”的概念。接口分为两种。

  • 实例接口(Object Interface),在Java中声明一个类,然后new关键字产生一个实例,它是对一个类型的事物所具有的方法特征的描述,也称作一个“接口”,这仅是一种逻辑上的抽象。
  • 类接口(Class Interface),是指在Java中使用interface严格定义的接口。

针对“接口”这两种不同的含义,接口隔离原则的表达方式以及含义都有所不同,接口隔离原则有如下两种定义。

第一种:
Clients不应该依赖它不需要的接口。

第二种:
类间的依赖关系应该建立在最小的接口上。

接口隔离原则的具体含义如下:

  • 一个类对另一个类的依赖性应当建立在最小的接口上。
  • 一个接口代表一个角色,不应当将不同的角色都交给一个接口。没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染。
  • 不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构,即不要强迫客户使用它们不用的方法,否则这些客户就会面临由于这些不使用的方法的改变所带来的改变。

例子:电子商务系统

接口隔离原则的应用场合,只提供调用者需要的方法,屏蔽不需要的方法。
在这里插入图片描述
IOrderForPortal.java

//用户门户应用接口
public interface IOrderForPortal{
	public String getOrder();
}

IOrderForOtherSys.java

//外部系统应用接口
public interface IOrderForOtherSys{
	public void insertOrder();
}

IOrderForAdmin.java

//管理平台应用接口
public interface IOrderForAdmin{
	public String getOrder();
	public void insertOrder();
	public void updateOrder();
	public void deleteOrder();
}

Order.java

public class Order implements IOrderForAdmin,IOrderForOtherSys,IOrderForPortal{
	//返给Portal
	public static IOrderForPortal getOrderForPortal(){
		return new order();
	}
	//返给OtherSys
	public static IOrderForOtherSys getOrderForOtherSys(){
  		return new order();
	}
	//返给Admin
 	public static IOrderForAdmin getOrderForAdmin(){
    		return new order();
 	}
 	public void deleteOrder(){
 		System.out.println("删除订单")}
 	public String getOrder(){
 		return "返回订单";
 	}
 	public void insertOrder(){
 		System.out.println("插入订单")}
 	public void updateOrder(){
 		System.out.println("更新订单")}
}

开闭原则(OCP)

开闭原则的英文名称是Open-Closed Principle。

定义

一个软件实体应当对扩展开放,对修改关闭。

这个原则说的是,在设计一个模块的时候,应当使这个模块可以不被修改的前提下被扩展,即应当可以在不必修改源代码的情况下改变这个模块的行为

开闭原则的重要性可以通过以下几个方面来体现:

  • 开闭原则提高复用性。(开闭原则的设计保证系统是一个在高层次上实现了复用)
  • 开闭原则提高可维护性。(开闭原则对已有软件模块,特别是最重要的抽象层模块要求不能再修改,这就使变化中软件系统有一定的稳定性和延续性,便于系统维护)
  • 开闭原则提高灵活性。
  • 开闭原则易于测试。

例子:书店售书

在这里插入图片描述
如果需要添加新的方法,则如下图进行扩展
在这里插入图片描述

开闭原则解决问题的关键在于抽象化,把系统所有可能的行为抽象形成一个抽象底层,这个抽象底层规定出所有的具体实现必须提供的方法特征,给系统定义出一个一劳永逸、不再修改的抽象设计,此设计允许有无穷尽的行为再实现层被实现。

小结

  • 单一职责原则SRP(Single Responsibility Principle):一个类,只有一个引起它变化的原因,应该只有一个职责;
  • 里氏替换原则LSP(Liskov Substitution Principle):所有引用基类的地方必须能透明地使用其子类对象,反之则不行;
  • 在类中调用其他类时务必要使用父类或接口,如果不能使用父类或接口,则说明类的设计已经违背了LSP原则;
  • 如果子类不能完整地实现父类的方法,或者父类的某些方法在子类中发生“畸 变”,则建议断开父子继承关系,采用依赖、聚集、组合等关系替代继承;
  • 依赖倒置原则DIP(Dependence Inversion Principle):高层模块不应该依赖低层模块,两者都应依赖其抽象,抽象不依赖细节,而细节依赖抽象;
  • 依赖倒置原则在Java中的表现是:模块间的依赖通过抽象产生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生,接口或抽象类不依赖 于实现类,实现类依赖接口或抽象类;
  • 接口隔离原则ISP(Interface Segregation Principle):一个类对另外一个类的依赖性应当是建立在最小的接口上,使用多个专门的接口比使用单一的总接口要好;
  • 开闭原则OCP(Open-Close Principle):一个软件实体,如类、模块和函数应该对外扩展开放,对修改关闭。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值