Notes
Search…
Principle
设计不是强行遵守的,是一个平衡的选择。

基于接口而非实现编程

这条原则的英文是“Program to an interface, not an implementation”,出自 1994 年的 GoF,当时很多编程语言还没诞生,比如 Java,所以这里的接口不要理解为编程语言中的接口。这条原则的接口可以理解为编程语言中的接口或抽象类
这条原则将接口和实现分离,封装不稳定的实现,暴露稳定的接口。上游系统面向接口而非实现编程,不依赖不稳定的实现细节,降低耦合性、提高扩展性。
这个原则更加贴切的表述应该是“基于抽象而非实现编程”,这样表述更加体现这条原则的初衷。越抽象、越顶层、越脱离具体某一实现的设计,越能提高代码的灵活性,越能应对未来的需求变化。好的代码设计,不仅能应对当下的需求,而且在将来需求发生变化的时候,仍然能够在不破坏原有代码设计的情况下灵活应对。
怎么做到这条原则呢?
  • 函数命名不能暴露任何实现细节。比如 uploadToAliyun() -> upload()。
  • 封装具体实现。
  • 为实现类定义接口。
总之,要有抽象意识、封装意识、接口意识。在定义接口的时候,不要暴露任何实现细节。接口的定义只表明做什么,而不是怎么做。要多思考接口设计是否足够通用,是否能够做到在替换具体的接口实现的时候,不需要任何接口定义的改动。
那是不是需要给每个实现类都定义对应的接口呢? 凡事就讲一个“度”,如果在业务场景下,某个功能只有一种实现,未来不可能被替换,那么就没必要设计接口。

多用组合少用继承

继承是面向对象的四大特性之一,表示类之间 is-a 的关系,可以解决代码复用性的问题。

继承的问题

继承层次过深、过复杂会影响代码的可读性和可维护性。下面有个例子说明这个问题:
设计一个关于鸟的类,有个抽象类 AbstractBird,麻雀、乌鸦、格子都继承这个类。
大部分鸟会飞,那我们应该在 AbstractBird 类中增加 fly 方法吗?有两种选择:
  • 增加:有特例,比如鸵鸟,如果鸵鸟继承 AbstractBird,那么不符合认知;就算鸵鸟重写 fly 方法,抛出异常,这种方式虽然可以解决问题,但是不好用,因为一是违背了最小知识原则或迪米特原则,二是每种不能飞的鸟都需要重写。
  • 不增加:可以把 AbstractBird 派生出两个类 AbstractFlyableBird 和 AbstractUnFlyableBird,但是鸟不但有会飞属性,还有会叫属性,如果也这么做,那么就有三层抽象,四个抽象类。依次类推,是否会下蛋属性,那么类的个数就爆炸了。

组合的优势

我们可以利用组合(Composition)、接口、委托解决上述问题。我们可以定义 Flyable、Tweetable、EggLayable 接口,然后为每个接口提供实现类 FlyAbility、TweetAbility、EggLayAbility,最后具体的鸟类就实现相应的接口,并在类里面包含相应的接口实现类。如下示例代码:
public interface Flyable {
void fly()
}
public class FlyAbility implements Flyable {
@Override
public void fly() { //... }
}
public class Ostrich implements Tweetable, EggLayable {//鸵鸟
private Tweetable tweetable = new TweetAbility(); //组合
private EggLayable eggLayable = new EggLayAbility(); //组合
//... 省略其他属性和方法...
@Override
public void tweet() {
tweetable.tweet(); // 委托
}
@Override
public void layEgg() {
eggLayable.layEgg(); // 委托
}
}

组合和继承应该怎么选择

组合并不是完美的,继承并不是一无是处的。由上面可以看出,继承改写为组合需要做细粒度拆分,定义更多的类和接口。
如果类之间继承结构稳定,继承层次比较浅,继承关系不复杂,那么就可以使用继承。反之,系统越不稳定,继承很深,继承关系复杂,那么就尽量使用组合。
另外一些设计模式,装饰者模式(decorator pattern)、策略模式(strategy pattern)、组合模式(composite pattern)等都使用了组合关系,而模板模式(template pattern)使用了继承关系。
有些场景必须使用继承,比如有些函数的参数类型我们不能改变,但是想改变参数类的行为,那么就可以继承该参数类,重写相关方法。

单一职责原则

Single Responsibility Principle。
定义:A class or module should have a single responsibility。不要存在多于一个导致类变更的原因。
核心思想:一个类、接口、方法只负责一项职责。
不同的场景对同一个类的职责是否单一的判定,可能结果是不一样的。在某种场景下一个类的设计可能已经满足单一职责原则了,但在另外的场景可能就不满足了,需要继续拆分成粒度更细的类。所以,我们可以先写一个粗粒度的类,满足业务需求。随着业务的发展,如果粗粒度的类越来越庞大,代码越来越多,这个时候,我们就可以将这个粗粒度的类,拆分成几个更细粒度的类。这就是所谓的持续重构。
有下面这些方法可以判断是否需要拆分类了:
  • 类中的代码行数、函数、属性过多,影响可读性和可维护性;
  • 类依赖的其它类过多;
  • 私有方法过多;
  • 难给类取一个名字;
  • 类中大量的方法都是集中操作类中的某几个属性;
类的职责是否越单一越好呢?
不是的。如果拆分得过细,实际上会适得其反,反倒会降低内聚性,也会影响代码的可维护性。如 Serializer 有序列化和返序列化两个方法,如果把这个类拆分成 Serializer 和 Deserializer 两个类,那么当序列化协议换了之后,就需要同时修改两个类,如果只修改了一个,就会导致序列化后不能反序列化。

开闭原则

Open Closed Principle。
定义:Software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。一个软件实体,如类、模块、函数,应该对扩展开放,对修改关闭。
理解:添加一个新功能,应该是在已有代码基础上扩展代码(新增模块、类、方法),而不是修改已有代码(修改模块、类、方法)。
核心思想:用抽象构件框架,用实现扩展细节。
同样一个代码改动,在粗粒度下,被认为“修改”,在细粒度下,又可被认为是“扩展”。实际上,我们没必要纠结某个代码改动是“修改”还是“扩展”,回到开闭原则的初衷:只要没有破坏原有的代码运行,没有破坏原有的单元测试,那么这个代码改动就是合格的。
添加一个新功能,任何代码修改都没有是不可能的,我们要做的是尽量让修改操作更集中、更少、更上层,尽量让最核心、最复杂的部分满足开闭原则。
如何做到开闭原则?
  1. 1.
    时刻具备扩展意识、抽象意识、封装意识。写代码时,花时间思考未来的需求变更,事先留好扩展点。
  2. 2.
    23 种设计模式,大部分是为了解决扩展性而总结出来的,都是以开闭原则为指导原则的。提高代码扩展性的方法:多态、依赖注入、基于接口而非实现编程。

里式替换原则

Liskov Substitution Principle。
定义1:If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program.
定义 2:Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it。子类对象能够替换程序中父类对象出现的任何地方,并保证原来程序的逻辑行为不变及正确性不被破坏。
核心思想:design by contract,按照协议来设计。父类定义了函数约定,子类可以改变实现逻辑,但不能改变约定。约定包括:函数声明要实现的功能;对输入、输出、异常的约定;注释中的特殊说明。
违反 LSP 的例子?
  1. 1.
    违反了父类声明要实现的功能。比如父类订单排序按照金额排序,子类重新实现为按照日期排序。
  2. 2.
    违反对输入、输出、异常的约定。比如父类约定运行出错是返回 null,子类运行出错后抛出异常。
  3. 3.
    违反了父类在注释中的特殊说明。比如父类注释说明提取现金不能超过余额,但是子类重写后 VIP 可以透支。

接口隔离原则

Interface Segregation Principle。
定义:Clients should not be forced to depend upon interfaces that they do not use。用多个专门的接口,而不使用单一的总接口,客户端不应该依赖它不需要的接口。这里的客户端可理解为接口的调用者或使用者。
核心思想:一个类对一个类的依赖应该建立在最小的接口上。尽量细化接口,接口中的方法尽可能少。注意适度
与单一职责原则的差别?
  • 单一职责原则针对的是模块、类、接口的设计。接口隔离原则更侧重于接口的设计,它的思考角度也是不同的。
  • 接口隔离原则提供了一种判断接口的职责是否单一的标准:通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能,那接口的设计就不够职责单一。

依赖反转原则

Dependency Inversion Principle。
定义:High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstractions。高层模块不应该依赖低层模块,二者都应该通过抽象来相互依赖。另外,抽象不要依赖具体实现细节,具体实现细节依赖抽象。
核心思想:面向接口编程,而不应该面向实现编程。
在调用链上,调用者属于高层,被调用者属于低层。平时做业务开发时,高层模块依赖低层模块是没问题的。实际上,这条原则指导的是框架层面的设计。比如 Servlet 容器,Tomcat 是高层模块,我们编写的 Web 程序是低层模块,Tomcat 和应用程序没有依赖关系,两者都依赖于 Servlet 规范,这个规范就是抽象。

控制反转(IOC)

Inversion of Control。注意:这里的 IOC 与 Spring 的 IOC 不同
非控制反转的例子如下,所有的流程由程序员来控制:
public class UserServiceTest {
public static boolean doTest() {
// ...
}
public static void main(String[] args) {//这部分逻辑可以放到框架中
if (doTest()) {
System.out.println("Test succeed.");
} else {
System.out.println("Test failed.");
}
}
}
如果我们抽象出如下框架:
public abstract class TestCase {
public void run() {
if (doTest()) {
System.out.println("Test succeed.");
} else {
System.out.println("Test failed.");
}
}
public abstract void doTest();
}
public class JunitApplication {
private static final List<TestCase> testCases = new ArrayList<>();
public static void register(TestCase testCase) {
testCases.add(testCase);
}
public static final void main(String[] args) {
for (TestCase case: testCases) {
case.run();
}
}
}
我们只需要在框架预留的扩展点上加上测试逻辑就行:
public class UserServiceTest extends TestCase {
@Override
public boolean doTest() {
// ...
}
}
// 注册操作还可以通过配置的方式来实现,不需要程序员显示调用register()
JunitApplication.register(new UserServiceTest();
上面的例子就是通过框架来实现“控制反转”。框架提供一个代码骨架,用于组装对象、管理执行流程,程序员使用框架时,只需要在扩展点上添加自己的业务逻辑,然后框架来驱动整个程序流程。
所以,控制反转的理解是,“控制”指对程序流程的控制,“反转”是指在使用框架之前,程序员自己控制程序执行,使用框架后,流程由框架来控制。
控制反转并不是一种具体的实现技巧,而是比较笼统的设计思想。实现控制反转有模板设计模式、依赖注入等具体编码方法。

依赖注入(DI)

Dependency Injection。
不通过 new 的方式在类内部创建依赖类的对象,而是将依赖的类对象在外部创建好,通过构造函数、函数参数等方式传递(或注入)给类使用。
// 非依赖注入方式
public class Notification {
private MessageSender messageSender;
public Notification() {
this.messageSender = new MessageSender(); //此处有点像hardcode
}
}
// 使用Notification
Notification notification = new Notification();
// 依赖注入的实现方式
public class Notification {
private MessageSender messageSender;
public Notification(MessageSender messageSender) {
this.messageSender = messageSender;
}
}
//使用Notification
MessageSender messageSender = new MessageSender();
Notification notification = new Notification(messageSender);

依赖注入框架(DI Framework)

上面的依赖注入的例子如果涉及几百个类,那么程序员自己创建、组装容易出错。而这些工作与业务无关,完全可以抽象出框架来完成。
这个框架就是依赖注入框架,只需要通过框架的扩展点,简单配置一下需要创建的对象、它们之间的依赖关系,框架就自动帮我们创建对象、管理对象的生命周期等。
这些框架有,Google Guice、Java Spring 等。Spring 声称自己是控制反转容器,控制反转容器是一种非常宽泛的描述,DI 更具体、更有针对性。

KISS 原则

Keep It Simple and Stupid, Keep It Short and Simple, Keep It Simple and Straightforward.
总的来说,意思就是尽量保持简单。
不是代码行数越少就越简单。也不是代码逻辑复杂就违背了 KISS 原则,因为有些业务逻辑、算法逻辑本来就复杂。
那么怎么写出满足 KISS 原则的代码呢?
  • 不要使用同事可能不懂的技术。
  • 不要重复造轮子。
  • 不要过度优化。

YAGNI 原则

You Ain't Gonna Need It。意思就是不要过度设计。

DRY 原则

Don't Repeat Yourself。不要写重复的代码。
存在重复的代码不一定违反 DRY 原则,如下:
public class UserAuthenticator {
public void authenticate(String username, String password) {
if (!isValidUsername(username)) {
// ...throw InvalidUsernameException...
}
if (!isValidPassword(password)) {
// ...throw InvalidPasswordException...
}
//...省略其他代码...
}
private boolean isValidUsername(String username) {
// check not null, not empty
if (StringUtils.isBlank(username)) {
return false;
}
// check length: 4~64
int length = username.length();
if (length < 4 || length > 64) {
return false;
}
// contains only lowcase characters
if (!StringUtils.isAllLowerCase(username)) {
return false;
}
// contains only a~z,0~9,dot
for (int i = 0; i < length; ++i) {
char c = username.charAt(i);
if (!(c >= 'a' && c <= 'z') || (c >= '0' && c <= '9') || c == '.') {
return false;
}
}
return true;
}
private boolean isValidPassword(String password) {
// check not null, not empty
if (StringUtils.isBlank(password)) {
return false;
}
// check length: 4~64
int length = password.length();
if (length < 4 || length > 64) {
return false;
}
// contains only lowcase characters
if (!StringUtils.isAllLowerCase(password)) {
return false;
}
// contains only a~z,0~9,dot
for (int i = 0; i < length; ++i) {
char c = password.charAt(i);
if (!(c >= 'a' && c <= 'z') || (c >= '0' && c <= '9') || c == '.') {
return false;
}
}
return true;
}
}
如果把上面代码改成:
public class UserAuthenticatorV2 {
public void authenticate(String userName, String password) {
if (!isValidUsernameOrPassword(userName)) {
// ...throw InvalidUsernameException...
}
if (!isValidUsernameOrPassword(password)) {
// ...throw InvalidPasswordException...
}
}
private boolean isValidUsernameOrPassword(String usernameOrPassword) {
//省略实现逻辑
//跟原来的isValidUsername()或isValidPassword()的实现逻辑一样...
return true;
}
}
那么这样做是不对的,因为验证用户名和验证密码是两个事情,虽然验证逻辑目前一样,但是以后密码验证可能允许大写字母。违反了“单一职责原则”。
验证用户名和验证密码虽然逻辑重复,但是语义不重复。对于代码重复问题,可以抽象更细粒度的函数来解决。
不存在重复代码不一定意味着遵守 DRY 原则,如下:
public boolean isValidIp(String ipAddress) {
if (StringUtils.isBlank(ipAddress)) return false;
String regex = "^(1\\d{2}|2[0-4]\\d|25[0-5]|[1-9]\\d|[1-9])\\."
+ "(1\\d{2}|2[0-4]\\d|25[0-5]|[1-9]\\d|\\d)\\."
+ "(1\\d{2}|2[0-4]\\d|25[0-5]|[1-9]\\d|\\d)\\."
+ "(1\\d{2}|2[0-4]\\d|25[0-5]|[1-9]\\d|\\d)quot;;
return ipAddress.matches(regex);
}
public boolean checkIfIpValid(String ipAddress) {
if (StringUtils.isBlank(ipAddress)) return false;
String[] ipUnits = StringUtils.split(ipAddress, '.');
if (ipUnits.length != 4) {
return false;
}
for (int i = 0; i < 4; ++i) {
int ipUnitIntValue;
try {
ipUnitIntValue = Integer.parseInt(ipUnits[i]);
} catch (NumberFormatException e) {
return false;
}
if (ipUnitIntValue < 0 || ipUnitIntValue > 255) {
return false;
}
if (i == 0 && ipUnitIntValue == 0) {
return false;
}
}
return true;
}
上面两个函数代码虽然不重复,但是语义重复,即功能重复。可能是两个同事写的。
怎么提高代码复用性?
  • 减少代码耦合。
  • 满足单一职责原则。
  • 模块化。
  • 业务与非业务逻辑分离。
  • 通用代码下沉。
  • 继承、多态、抽象、封装。
  • 使用模板等设计模式。

迪米特原则

Law of Demeter。The Least Knowledge Principle。
定义:Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers。不该有直接依赖关系的类之间,不要有依赖;有依赖关系的类之间,尽量只依赖必要的接口。一个对象应该对其它对象保持最少的了解。又叫最少知道原则。
核心思想:尽量降低类于类之间的耦合。尽量只使用成员变量、方法的输入输出参数的类型,方法体内的新类型尽量不用。
高内聚,就是指相近的功能应该放到同一个类中,不相近的功能不要放到同一类中。“高内聚”用来指导类本身的设计,“松耦合”用来指导类与类之间依赖关系的设计。高内聚有助于松耦合,松耦合又需要高内聚的支持。