我真的很喜欢链接方法的哲学，例如其库中的jQuery emphasys。我发现它相当优雅和清晰。

作为主要的Java开发人员，我一直想知道为什么在这种语言中没有更多地使用这种做法。例如，Collection接口不是以这种方式设计的(用于添加/删除方法)，我感到非常可悲。

是否有反对这种做法的真正弊端，还是仅仅是在此之前没有足够的"性诉求"？

解决方案

我也非常喜欢这种方法。我能想到的唯一缺点是，在每种方法结束时"返回此值"有时看起来有些尴尬。例如，对于JQuery，它允许插件有点尴尬，因为我们必须说"确保我们不会忘记自己的回报！"但是没有很好的方法在编译时捕获它。

唯一的缺点是我们松开了返回类型，因此链接对于执行操作的操作很有用，但不适用于计算操作的操作。

另一个问题是，通过链接，编译器无法轻松确定用于内联的琐碎函数调用。但是正如我说的，如果链接是操作而不是计算，那么编译器很可能不会改变任何内容。

JavaScript是(或者多或者少)一种功能性语言，具有作为一等公民的功能。
向对象添加/删除方法，将函数作为参数传递，这对于该语言来说是很自然的。

另一方面，Java严格来说是OO，一个函数不能存在于类之外。对于这种语言，使用继承，组合和接口是一种更自然的方法。

IMO调试起来很麻烦，因为我们通常没有要检查的中间变量。

可链接方法是我们设计工具包中的另一个出色工具。只要确保我们不要碰到常见的"我有一把锤子，因此每个问题都是钉子"的设计混乱。

每个设计问题都不能通过可链接的方法来解决。有时它确实有助于使界面更易于使用(即，我们提到的集合问题)。有时并非如此。技巧是弄清楚哪种情况适用。

马丁·福勒(Martin Fowler)在http://www.martinfowler.com/bliki/FluentInterface.html上以"流畅的界面"的形式讨论了该主题。一个主要问题是流利的接口是为人类设计的，因此诸如Spring之类的框架无法理解它们。简单地说，使用流畅的界面可以在某种意义上提供可维护性(可读性)，而在另一种意义上则失去可维护性(灵活性)。

可链接方法和继承存在一个常见问题。假设我们有一个类C，其方法F1()，F2()等返回C。从C派生类D时，我们希望方法F1，F2等现在返回D，以便D的可链接方法可以被称为链中的任何地方。