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才有流畅的可能性。
