可链接方法的优点和缺点？

Question

我真的很喜欢链接方法的哲学，比如jQuery强调它的库。我发现它非常优雅和清晰。

作为主要的Java开发者，我一直在想自己为什么这种做法在这种语言中没有被更多地使用。例如，Collection接口没有以这种方式设计（用于添加/删除方法），我发现它非常难过。

这种做法是否有真正的缺点，或者只是之前没有足够的“性吸引力”？

Answer 1

IMO调试很痛苦，因为您往往没有中间变量可供检查。

Answer 2

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

Answer 3

我也非常喜欢这种方法。我能想到的唯一不利因素是，在每种方法结束时“回归”这个问题似乎有点尴尬。例如，对于JQuery来说，允许插件有点尴尬，因为你必须说“确保你不要忘记你的回报!!”但是没有好的方法可以在编译时捕获它。

Answer 4

唯一的缺点是你放松了返回类型，因此链接对于做事情的操作很有用，但对计算事物的操作不利。

另一个问题是，链接编译器不能轻易确定内联的简单函数调用。但正如我所说，如果你的链接执行操作而不是计算，那么编译器最有可能不会改变任何东西。

Answer 5

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

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

Answer 6

可连接方法是我们设计工具包中的另一个很棒的工具。只要确保你没有碰到常见的“我有一把锤子，因此每个问题都是钉子”设计混乱。

每个设计问题都没有通过可链接的方法解决。有时它确实有助于使界面更易于使用（即您提到的集合问题）。有时却没有。诀窍是弄清楚哪种情况适用。

Answer 7

Martin Fowler在http://www.martinfowler.com/bliki/FluentInterface.html讨论了这个主题为“流畅的界面”。一个主要问题是流畅的界面是为人类设计的，因此像Spring这样的框架无法理解它们。简单地使用流畅的界面在某种意义上提供可维护性（可读性）但在另一种意义上失去可维护性（灵活性）。