英文阿里巴巴网站建设,企查查官网查询,兴平做网站,平台推广具体是干啥声明式编程与函数式编程最近#xff0c;我被指控反对函数式编程#xff0c;因为我将实用程序类称为反模式 。 绝对是错的#xff01; 好吧#xff0c;我确实认为它们是一个糟糕的反模式#xff0c;但是它们与函数式编程无关。 我相信有两个基本原因。 首先#xff0c;函数… 声明式编程与函数式编程 最近我被指控反对函数式编程因为我将实用程序类称为反模式 。 绝对是错的 好吧我确实认为它们是一个糟糕的反模式但是它们与函数式编程无关。 我相信有两个基本原因。 首先函数式编程是声明性的而实用程序类的方法则是必需的。 其次函数式编程基于lambda演算其中可以将函数分配给变量。 从这个意义上说实用程序类方法不是函数。 我将在一分钟内对这些语句进行解码。 在Java中对于Guava Apache Commons等人积极推广的这些丑陋的实用程序类基本上有两种有效的替代方法。 第一个是传统类的使用第二个是Java 8 lambda 。 现在让我们看看为什么实用程序类与函数式编程甚至不一样以及这种误解来自何处。 彩色我库布里克2005 这是来自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以来在Java的第一个版本中引入了Math类这些实用程序类随处可见。 好吧从技术上讲没有错。 该代码将起作用。 但这不是面向对象的编程。 相反它是必须的和程序的。 我们在乎吗 好吧由您决定。 让我们看看有什么区别。 基本上有两种不同的方法声明式和命令式。 命令式编程的重点是描述一个程序在改变程序状态的语句方面如何运作的 。 我们刚刚在上面看到了命令式编程的示例。 这是另一种这是与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(maxabs 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函数将不会被调用。 当您尝试“购买” 1至5之间的最大值时此x是返回给您的“凭证”。 但是请注意将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文件中当它超过十二种静态方法时该文件将变得绝对无法维护。 最后让我重申一下实用程序类与函数式编程无关。 它们只是静态方法的包这是命令程序。 无论您要声明多少个物体又要缩小多少物体都应尽量远离它们并使用坚固的有凝聚力的物体。 翻译自: https://www.javacodegeeks.com/2015/03/utility-classes-have-nothing-to-do-with-functional-programming.html声明式编程与函数式编程
