实用程序类与函数式编程无关

最近，我被指控反对函数式编程，因为我将实用程序类称为反模式。绝对是错的！好吧，我确实认为它们是一种糟糕的反模式，但是它们与函数式编程无关。我相信有两个基本原因。首先，函数式编程是声明性的，而实用程序类的方法则是必不可少的。其次，函数式编程基于lambda演算，其中可以将函数分配给变量。从这个意义上说，实用程序类方法不是函数。我将在一分钟内解码这些语句。

在Java中，对于Guava ， Apache Commons等人积极推广的这些丑陋的实用程序类，基本上有两种有效的替代方法。第一个是传统类的使用，第二个是Java 8 lambda 。现在，让我们看看为什么实用程序类与函数式编程甚至不一样，以及这种误解来自何处。

彩色我库布里克（2005）：布莱恩·库克（Brian W. Cook）

这是来自Java 1.0的实用程序类Math的典型示例：

public class Math {public static double abs(double a);// a few dozens of other methods of the same style
}

当您要计算浮点数的绝对值时，将使用以下方法：

double x = Math.abs(3.1415926d);

它出什么问题了？我们需要一个函数，并且可以从Math类中获得它。该类内部有许多有用的函数，可用于许多典型的数学运算，例如计算最大值，最小值，正弦，余弦等。只看任何商业或开源产品。自发明Java以来，这些实用程序类到处都有使用（此Math类是在Java的第一个版本中引入的）。好吧，从技术上讲没有错。该代码将起作用。但这不是面向对象的编程。相反，它是必须的和程序的。我们在乎吗？好吧，由您决定。让我们看看有什么区别。

基本上有两种不同的方法：声明式和命令式。

命令式编程的重点是描述一个程序在改变程序状态的语句方面如何运作的。我们刚刚在上面看到了命令式编程的示例。这是另一个（这是与OOP无关的纯命令式/过程式编程）：

public class MyMath {public double f(double a, double b) {double max = Math.max(a, b);double x = Math.abs(max);return x;}
}

声明式编程的重点是程序应该完成什么不规定如何做到这一点的动作序列方面采取。这就是在功能编程语言Lisp中相同代码的外观：

(defun f (a b) (abs (max a b)))

有什么收获？语法不同吗？并不是的。

命令式和声明式之间的区别有很多定义，但是我会尽力而为。在此方案中，与该f函数/方法交互的角色基本上有三个：买主，结果打包者和结果消费者 。假设我这样调用此函数：

public void foo() {double x = this.calc(5, -7);System.out.println("max+abs equals to " + x);
}
private double calc(double a, double b) {double x = Math.f(a, b);return x;
}

在这里，方法calc()是买方，方法Math.f()是结果的打包程序，而方法foo()是消费者。无论使用哪种编程风格，总有以下三个人参与：购买者，包装者和消费者。

假设您是买家，并且想为您的（女友）朋友购买礼物。第一种选择是去一家商店，支付50美元，让他们为您包装香水，然后将其交付给朋友（并得到一个吻）。这是当务之急的风格。

第二种选择是去一家商店，支付50美元，并获得一张礼品卡。然后，您将此卡片出示给朋友（并得到一个吻）。当他或她决定将其转换为香水时，他或她将前往商店并购买。这是一种声明式样式。

看到不同？

在第一种情况下，当务之急是，您迫使包装商（一家美容店）找到库存的香水，将其包装，然后将其作为即用型产品展示给您。在第二种情况下，这是声明性的，您只是从商店那里得到了一个承诺，即最终，在必要时，工作人员会找到库存的香水，将其包装，然后提供给需要的人。如果您的朋友从不使用该礼品卡去商店，则香水将保留库存。

而且，您的朋友可以将该礼品卡用作产品本身，而无需访问商店。他或她可以代之以将其作为礼物赠送给其他人，或仅将其换成另一张卡或产品。礼品卡本身就是产品！

因此，区别在于消费者所得到的是-可以使用的产品（必须）或该产品的凭证，可以在以后将其转换为真实的产品（说明性）。

实用程序类（例如JDK中的Math或Apache Commons中的StringUtils返回准备立即使用的产品，而Lisp和其他功能语言中的函数返回“凭单”。例如，如果您在Lisp中调用max函数，则只有在您实际开始使用它时，才计算两个数字之间的实际最大值：

(let (x (max 1 5))(print "X equals to " x))

在此print实际开始将字符输出到屏幕之前， max函数将不会被调用。 x是您尝试“购买” 1至5之间的最大值时返回给您的“凭单”。

但是请注意，将Java静态函数一个嵌套到另一个嵌套并不能使它们具有声明性。该代码仍然势在必行，因为它的执行可以在此处和现在提供结果：

public class MyMath {public double f(double a, double b) {return Math.abs(Math.max(a, b));}
}

“好吧，”您可能会说，“我明白了，但是为什么声明式风格比命令式风格更好？有什么大不了的？” 我明白了。首先让我展示一下函数编程中的函数与OOP中的静态方法之间的区别。如上所述，这是实用程序类和函数式编程之间的第二大区别。

在任何函数式编程语言中，您都可以这样做：

(defun foo (x) (x 5))

然后，稍后可以将其称为x ：

(defun bar (x) (+ x 1)) // defining function bar
(print (foo bar)) // passing bar as an argument to foo

就函数式编程而言，Java中的静态方法不是函数。您无法使用静态方法执行任何此类操作。您可以将静态方法作为参数传递给另一个方法。基本上，静态方法是过程，或者简而言之，是以唯一名称分组的Java语句。访问它们的唯一方法是调用过程并将所有必要的参数传递给该过程。该过程将计算出一些内容并返回立即可以使用的结果。

现在我们可以听到最后一个问题，我可以听到你问：“好吧，实用程序类不是函数式编程，但是它们看起来像函数式编程，它们运行非常快，并且非常易于使用。为什么不使用它们？当20年的Java历史证明实用程序类是每个Java开发人员的主要工具时，为什么要追求完美？”

除了我经常被指控的OOP原教旨主义外，还有一些非常实际的原因（顺便说一句，我是OOP原教旨主义者）：

可测性 。对实用程序类中的静态方法的调用是硬编码的依赖项，出于测试目的，它们永远不会被破坏。如果您的班级正在调用FileUtils.readFile() ，那么在不使用磁盘上实际文件的情况下，我将永远无法对其进行测试。

效率。实用程序类由于其强制性而比它们的声明性替代方法效率低得多。他们只是在此时此地进行所有计算，即使在没有必要的情况下也占用处理器资源。 StringUtils.split()不会返回将字符串分解成块的承诺，而是立即将其分解。即使“买方”只要求第一个，它也将其分解为所有可能的块。

可读性 。实用程序类往往很大（尝试从Apache Commons读取StringUtils或FileUtils的源代码）。实用程序类中缺少关注点分离的整个想法，这使OOP如此美观。他们只是将所有可能的过程放入一个巨大的.java文件中，当它超过十二种静态方法时，该文件将变得绝对无法维护。

最后，让我重申一下：实用程序类与函数式编程无关。它们只是静态方法的包，这是命令程序。无论您要声明多少个物体，又要缩小多少物体，都应尽量远离它们并使用坚固的，有凝聚力的物体。