什么叫流畅API?

  1. 云栖社区>
  2. 博客>
  3. 正文

什么叫流畅API?

山月风成 2017-11-09 16:00:35 浏览569
展开阅读全文

1.命令查询分离概念

  • 流畅API是什么?什么是流畅API?为什么要使用流畅API这种方式?
  • 目前很多的编程语言都有方法链串(Method chaining),创造出流畅语义。比较熟悉的就有JQuery,$(‘#id’).css(’color’);而Guava中有如ComparisonChain、Ordering也采用了此风格,这种方法链串的形式就是流畅API的设计思想的表现形式之一。

  • 在探讨流畅API设计之前,得先了解命令查询分离(Command Query Separation)的概念,Martin Fowler的文章〈CommandQuerySeparation〉指出——将类的方法分为命令与查询两类。
  • 改变系统状态但不传回值的方法称为命令,传回结果但不改变系统状态的方法称为查询。

  • 比如说,在JDK中,Calendar类,具备命令查询分离概念,set、add、roll等方法是改变了Calendar实例的方法,返回值都是void,而查询结果的get等方法,并不改变实例状态。Martin Fowler提到采用此原则的好处是,对于一个状态可变的实例来说,可以清楚地辨别哪些操作会有副作用(Side effect)而哪些不会。

  • 你可以将实例传递给需要查询的场合,而不用担心会改变状态和内容;另一个好处是,查询方法的传回型态可标识对象命令操作后的差异性,以Iterator的next方法为例,依命令查询分离思想,将之分开为advance与current方法,会是偏好的设计方式。
  • 命令查询分离概念的优点是方法的职责清楚(后来又演变出CQRS模式)。然而缺点是有时必须透过一连串的命令操作,方可获得想要的物件状态,容易形成冗长的程序,以Calendar类别为例,若想知道1975年5月26日五天后的六个月又三星期是什么日子,在通过Calendar.getInstance()取得Calendar实例后,一段冗长的代码:
calendar.set(1975, Calendar.MAY, 26, 0, 0, 0);
calendar.add(Calendar.DAY_OF_MONTH, 5);
calendar.add(Calendar.MONTH, 6);
calendar.add(Calendar.WEEK_OF_MONTH, 3);

2.方法链串/不可变事物的连续

  • 不可变事物的连续 是比较多见的方式,方法的连续链串就是这样的。命令查询分离在概念上,是将变更实例状态的“命令”与对象状态的“查询”在方法的职责上加以分离。
例如对一个对象的实例A进行操作时,返回值仍然是一个对象B,那就可以直接对传回的对象进行操作,形成链状操作。
Java的字符串是个明显的例子,因为String实例是不可变,进行如下的链结操作:
param.trim()
     .toLowerCase()
     .replace(regx, mask);
  • 这种方法比每执行一个方法操作之后,用一个变量来接收结果,再通过变量进行下一步操作简介。且不违反命令查询分离概念,因为你并没有改变实例状态,而是基于目前实例状态,(也就是查询后)建立新实例。像是同样想知道1975年5月26日五天后的六个月又三星期是什麽日子,利用JSR310可以写为LocalDate.of(1975, 5, 26).plus(5, DAYS).plus(6, MONTHS).plus(3, WEEKS),相较于Calendar的操作简洁许多,代码一目了然。

3.可读性才是是流畅API出发点

  • 流畅的行为可读性是流畅API的出发点。

  • 命令查询分离只是一个概念,方法链串有体现这种思想,又不完全拘泥这种编程思想或者说习惯。代码的流畅可读性是高于此种原则的,将命令与查询方法合并,这种现象在编程语言中并不少见,基于命令查询分离的思想,在jQuery的css方法是命令方法——('#some').css('color', 'red'),也是查询方法——(‘#some’).css(‘color’),在Java中可以用重载(Overload)方法来达到相同目的,以某些程度来说,它就是Getter方法和Setter方法的结合。

  • 总结来说:方法链串是基于命令查询分离思的流畅API常见方式,而不是唯一方式。
  • 流畅API的重点在:大部份设计原则考量的都是职责清晰,降低藕合度,必定优先遵守,基于命令查询分离的概念来说,设计API时应该优先考量这种思想,其次在一些语义明确或惯例的情境下,若有助于可读性则可考虑变通。作为开发人员在类的方法的返回值、名称、型态上,要多下点功夫,一切都以可读性为出发点,API才有流畅的可能性。

网友评论

登录后评论
0/500
评论
山月风成
+ 关注