1、单一职责原则(Single Responsibitity Principle)
一个类或者模块只负责完成一个职责;
【实例】
上面这个类,当此类只是用来展示用户信息,则设计符合单一职责;当此用户的地址经常需要使用,比如电商平台类的项目,则需要将地址信息分离出来才符合单一职责。
1.1 如何判断一个类是否违反单一职责
- 类中代码行数、函数、属性过多
- 类依赖的其他类过多(如果某个 service 类需要依赖多个不同功能的 service 类来完成一个复杂的业务逻辑,但自身的职责仍然是单一的,那么这也是符合单一职责原则的)
- 私有方法过多
- 类中的大量的方法总是操作类中的几个属性(这种时候这几个属性可能构成独立职责)
2、开闭原则(Open Close Principle)
软件当中的对象、类、模块和函数对扩展应当开放,对于修改应该封闭;
【实例】
系统A与系统B之间进行数据传输使用的是427版本的协议,一年以后对427版本的协议进行了修正;设计时应该考虑的数据传输协议的可变性,抽象出具有报文解译、编制、校验等所有版本协议使用的通用方法 ;
2.1 如何保证开闭原则的实现
需要培养顶层设计思维:
- 抽象意识:要求我们在编写代码时尽量定义抽象(如接口或抽象类),而不是具体的实现;这使得我们能够在需要扩展功能时,通过实现新的具体类而不是修改已有类的方式来实现。
- 封装意识:要求我们将变化的细节封装起来,通过稳定的接口对外提供服务。这样,当需要更改内部实现时,对外部使用者的影响最小。
- 扩展意识:设计灵活的体系结构,使系统能够通过添加新代码来实现扩展,而不是修改现有代码。
3、里氏替换原则(Liskov Substitution Principle)
子类对象能够替换程序中父类对象出现的任何地方,并且保证原来程序的逻辑行为不变及正确性不被破坏。
【实例】
如在一个商城项目中, 定义结算接口Istrategy,该接口有三个具体实现类,分别为 PromotionalStrategy (满减活动,两百以上打八折)、RebateStrategy (打折活动)、 ReduceStrategy(返现活动)
结算接口与三个实现类:
public interface Istrategy {
public double realPrice(double consumePrice);
}
public class PromotionalStrategy implements Istrategy {
public double realPrice(double consumePrice) {
if (consumePrice > 200) {
return 200 + (consumePrice - 200) * 0.8;
} else {
return consumePrice;
}
}
}
public class RebateStrategy implements Istrategy {
private final double rate;
public RebateStrategy() {
this.rate = 0.8;
}
public double realPrice(double consumePrice) {
return consumePrice * this.rate;
}
}
public class ReduceStrategy implements Istrategy {
public double realPrice(double consumePrice) {
if (consumePrice >= 1000) {
return consumePrice - 200;
} else {
return consumePrice;
}
}
}
调用方
public class Context {
//使用基类定义对象变量
private Istrategy strategy;
// 注入当前活动使用的具体对象
public void setStrategy(Istrategy strategy) {
this.strategy = strategy;
}
// 计算并返回费用
public double cul(double consumePrice) {
// 使用具体商品促销策略获得实际消费金额
double realPrice = this.strategy.realPrice(consumePrice);
// 格式化保留小数点后1位,即:精确到角
BigDecimal bd = new BigDecimal(realPrice);
bd = bd.setScale(1, BigDecimal.ROUND_DOWN);
return bd.doubleValue();
}
}
4、接口隔离原则(Interface Segregation Principle)
客户端不应该被迫依赖于他不使用的方法。 --《代码整洁之道》
要为各个类建立他们需要的专用接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用;
【实例】
实现删除用户的功能遵照接口隔离原则,为依赖接口的类定制服务。只提供调用者需要的方法,屏蔽不需要的方法。
将删除接口单独放到另外 一个接口 RestrictedUserService 中, 然后将 RestrictedUserService 只打包提供给后台管理系统来使用。
5、依赖倒置原则(Dependence Inversion Principle)
高层模块不应该依赖于底层模块,二者都应该依赖于抽象;抽象不应该依赖于细节,细节应该依赖于抽象。
【实例】
假设需要组装一台电脑,需要cpu、硬盘、内存等,具体的配置有多种品牌的选择;
这样设计电脑就可以随意搭配不同品牌配置,使得代码更加灵活;
6、迪米特法则(Law Of Demter)
一个类(模块)对其他的类(模块)有越少的了解越好;
【实例】
如明星与经纪人、粉丝之间的关系
明星不需要对粉丝有过多了解,他们之间的互动通过经纪人来运行;
- 通过中介会避免过于耦合的关系,但是中介多了又会增加复杂性,降低模块之间的通信效率;