从标题最后的一个序就能看出来,本篇主要是为了为这一个fluent-style这个系列做个铺垫。
话不多说,先对着fluent-style问问四个问题。
image.png细化来讲,FluentStyle这种链式风格会一定程度上提升代码的可读性,并且在书写的过程中也会提升书写的流畅感,举个列子来说。
原来我们创建一个对象,可能是这么写。
public class Car {
/**
* 品牌
*/
private String brand;
/**
* 颜色
*/
private String color;
public String getBrand() {
return brand;
}
public void setBrand(String brand) {
this.brand = brand;
}
public String getColor() {
return color;
}
public void setColor(String color) {
this.color = color;
}
public static void main(String[] args) {
Car car = new Car();
car.setBrand("保时捷");
car.setColor("银色");
}
}
而fluentStyle风格下,代码是这样的
public class CarFluentStyle {
/**
* 品牌
*/
private String brand;
/**
* 颜色
*/
private String color;
public String getBrand() {
return brand;
}
public CarFluentStyle setBrand(String brand) {
this.brand = brand;
return this;
}
public String getColor() {
return color;
}
public CarFluentStyle setColor(String color) {
this.color = color;
return this;
}
private CarFluentStyle() {
}
public static CarFluentStyle build() {
return new CarFluentStyle();
}
public static void main(String[] args) {
CarFluentStyle car = CarFluentStyle
.build()
.setBrand("保时捷")
.setColor("银色");
}
}
可以看出来的是,这种通过“.”语法的链接,似乎确实有了一些流畅感的提升,不过这也是因人而异,可能有些同学觉得这样更难读也不好说。
实际上,这种链式语法在每次方法调用返回自身的做法很适合在深层代码架构生发挥作用,比如我们在书写流程代码时,对入参的检查,重构,赋值,触发外部调用等等流程,如果通过这种链式来解决,外部一个catch抓住各种异常,整个主业务代码看起来一定会简洁不少!
但是话又说话来,有得必有失,代码简洁了,牺牲的就是一定的自由度,我们必须在流程阻断的时候抛出一个异常,而不能简简单单的返回一个null,否则在一整条链路上,我们很难知道是哪里出了问题。同理,debug的难度也更高了,毕竟一行一行debug肯定要比这样链式的debug要方便一些。
接下里的关于FluentStyle这个系列,会尽量根据实际例子再补充进我对于FluentStyle的理解。
网友评论