在 Clojure 的宏中声明设计模式

Question

Lisp 的优点之一是宏。我读过很多关于在 Java 中一次又一次编写设计模式的文章。不在 Lisp/Clojure 中。
在 Lisp/Clojure 中，您可以在宏中声明该模式，并且只需编写实际的代码。

好吧，漂亮又花花公子，但眼见为实。

您能否向我提供（或推荐我）一个包含代码的示例（最好是 Clojure），说明如何在宏中声明设计模式？

Answer 1

大多数现有的设计模式都起源于面向对象的世界，并且仅在面向对象的世界中才有意义。一旦您进入函数式编程，尤其是像 Clojure 这样的 Lisp 方言，您对设计模式的需求就会变得越来越小。 此处有关于设计模式和 FP 的有趣讨论。

另一方面，宏并不是为了封装设计模式，而是通过更方便地解决当前问题的结构来扩展语言。采取 with-open宏：将其称为对资源调用 close 的设计模式似乎完全错误。

模式也存在于 FP 世界中，但由于不再有对象，因此它们的主要焦点是算法。 FP 语言的“模式”的好例子是 monad 和 拉链。

警告：理解这些概念可能需要一些时间，但绝对值得理解它们的每一个部分。

Answer 2

实现设计模式的典型宏用法示例是应用于现有函数的“装饰器”模式。

; a simple function
(defn square [x] (* x x))

; a macro to "decorate" a function with a debug output println
(defmacro with-debug-output [f] 
  `(fn [& args#] 
     (let [result# (apply ~f args#)]
       (println (str "Debug-output: " result#))
       result#)))


; call the straight function
(square 16)
=> 256

; call the decorated function
((with-debug-output square) 16)
Debug-output: 256
=> 256

注意：您实际上并不需要宏来执行此操作，您也可以使用高阶函数来执行此操作。

Answer 3

它不是关于宏，而是关于函数式编程。宏可以让东西看起来更好，感觉更好，但一切都与功能有关。如果你用 FP 编写，你不会遇到很多必须一直重复的习惯用法（至少没有一个是你不能用更多的函数做得更好的）。

采用策略模式。如果您的语言有 lambda，您就不再需要它了。

通常，您可能会使用相同的模式，但您的语言使表达它变得如此容易，以至于您永远不会将其称为“实现设计模式”。这只是编程。

Answer 4

到目前为止所有好的答案。我想强调的是，宏和函数之间的关键实际区别在于，宏可以控制何时以及是否评估其参数，而函数则不能。除其他含义外，这允许您用该语言编写新的控制结构，而这是函数无法做到的。

例如，查看 if-not来自 Clojure 核心的宏。这与标准的“if”完全相同，但相反：如果条件为假，则运行第一位代码；如果条件为假，则运行第一位代码。如果条件为真，则运行第二个。

如果你写了类似函数的东西，那是行不通的。函数版本将在调用函数时立即运行“then”和“else”代码，无论条件为真还是假。另一方面，宏版本可以选择是否（以及何时）运行作为参数给出的代码。

一个不太简单的例子是 抽象出典型的“尝试” ... catch ... finally”控制结构在 Java 中无处不在，在其他语言中也很常见，变成了“with-whatever”宏。如果您持有有限的资源，例如必须释放的文件句柄或网络套接字，即使出现错误，您也需要一个“finally”块来执行此操作，但您的应用程序代码必须未经评估地拼接到“try”块的内部，在该上下文中运行。

您最终会在程序中的任何地方复制本质上相同的未更改的样板 try...catch...finally 块，并将一个小的本地适用部分粘贴到“try”部分中。 （查看任何重要的 Java 源代码。）此样板文件无法抽象为函数，因为函数在调用时会在调用者的上下文中立即计算本地代码，然后给出结果 /em> 该代码到“with-whatever”函数。

另一方面，宏可以延迟求值，直到宏代码特别要求为止，从而允许它将任意本地代码拼接到未求值的“try”构造的内部。然后，整个结果（整个 try/catch/finally，包括 try 中未评估的应用程序特定代码）返回给调用者并拼接到调用者的上下文中，完成，以便在那里执行。

因此，您可以编写一个可以编写程序的程序。