递归-是“分而治之”还是“代码重用”

递归 -众所周知-是其中的一个问题-绕回头就像在编程之旅中取得“里程碑”。

但是，当涉及到在现实世界中实际使用它时-仅了解递归的机制还不够-在递归是最合适的解决方案的同时，还必须了解问题的性质。

所以我的问题是...

• 什么是需要递归解决的“问题模式”
• 是递归形式的“分而治之”策略还是形式的“代码重用”，或者是一种设计模式
• 您能否举一个现实世界中的示例为例，其中想到递归作为直接解决方案

-更新-

许多答案都将“实际问题”称为遍历树，阶乘等。我更喜欢“真正的实际问题”-让我举个例子...

我们有一个大的文本夹（大约30 MB的文本作为的链接列表structs），我们需要为全文搜索创建一个索引。我们需要将整个索引保留在内存中，然后每10分钟重新为文本建立索引。

每隔10分钟，我们会将整个文本（两个链接列表，逐行）与新生成的文本块进行比较-以查看更改了哪行-然后我们将仅对该行重新索引-这样我们可以避免不必重新索引整个文本。记住-我们需要找到两个30 MB链表之间的差异点。

我的一位同事提出了一个很棒的程序，该程序使用HEAVY递归比较行-然后收集卡盘在阵列中不同的位置-是的，我知道这听起来很令人困惑-递归如何在这里提供帮助-但它做了。

关键是-他怎么看待大量使用递归可以巧妙地解决这个问题？

• 什么是需要递归解决的“问题模式”

我不会说存在类似使用递归的问题模式之类的问题。可以递归实现的每个函数也可以迭代地实现，通常是通过压入和弹出堆栈来实现的。

这是表达的问题，也是性能的问题。迭代算法通常具有更好的性能并且更易于优化。但是，递归算法受益于更清晰的表达式，因此通常更易于阅读，理解和实现。

有些事情甚至无法递归表示，例如无限列表。所谓的功能语言在很大程度上依赖于递归，因为它是自然的表达方式。俗话说：“递归编程是正确完成功能编程”。

• 是递归形式的“分而治之”策略还是形式的“代码重用”，或者是一种设计模式

我不会称其为设计模式。这是表达的问题。有时，递归表达式只是功能更强大，表达能力更强，因此可以生成更好更简洁的代码。

• 您能否举一个现实世界中的示例为例，其中想到递归作为直接解决方案

任何需要遍历树的东西都将由递归算法正确表达。

是递归形式的“分而治之”策略还是形式的“代码重用”，或者是一种设计模式

都不行 分而治之使用递归。但是递归并不一定是分而治之，因为后者意味着将一个问题分为两个（或更多）部分并对称地解决每个部分。递归时，您无需执行此操作。

代码重用是完全不相关的，设计模式在更高层次上起作用。例如，即使分而治之（也是比递归更高级的模式）仍不被视为设计模式-而是一种算法模式。

您能否举一个现实世界中的示例为例，其中想到递归作为直接解决方案

树遍历。或更一般而言，图形遍历。值得注意的是，这包括遍历文件夹结构。

当然，任何使用分而治之或动态编程的方法，因为两者自然都以递归的方式表示。

what are the "problem patterns" that call for the solution of recursion

从分形的自相似​​性出发，我想说自相等或自同一性（或称其为自称为）是递归的典型问题模式。即，一个问题可以分为与主要问题具有相同结构的子问题。

在提到的树遍历中，每个子树本身就是一棵完整的树，就像主树一样，并且主树可以是另一棵树内的子树。

因此，我想您的同事发现了索引问题的自平等属性。或者他反过来将问题转化为自我平等的表示。

好吧，如果人们尝试将命令式循环转换为功能函数，则可以很容易地理解递归。无论如何，让我们尝试为所有问题提供答案：

什么是需要递归解决的“问题模式”

如果您具有树状结构或算法，则需要递归。如果命令性代码处理堆栈，则需要递归。如果算法中的某个步骤取决于先前的步骤（思考循环），则需要递归。这里需要将其解释为可以使用。

是递归形式的“分而治之”策略还是形式的“代码重用”，或者是一种设计模式

没有。分而治之使用递归，但可以通过堆栈实现。代码重用是指其他内容。设计模式比简单的递归更为复杂。

您能否举一个现实世界中的示例为例，其中想到递归作为直接解决方案

解析以及与树结构有关的所有内容。甚至隐式树结构。

如果有一种方法可以简化它，使其很容易，那么这可能是递归起作用的线索。您可以进行排序和搜索，以找到确实存在递归解决方案的示例，例如分别存在合并排序和二进制搜索。

需要记住的一点是，如何像阶乘一样通过递归来解决一些问题。

对于使用递归的真实示例，可以很容易地以递归方式在书架上查找书籍。我只是看书，如果不是我想要的书，那么我继续下本书。当我找到书或碰到行尾时，我停了下来。可以递归地完成检查一本书并转到下一本书的循环。也许这是一个真实的例子。

什么是需要递归解决的“问题模式”

一般来说，解决f（x）= f（g（x））的问题时需要进行递归。除非您对无限递归感到满意，否则g（x）不应求值为x。

是递归形式的“分而治之”策略还是形式的“代码重用”，或者是一种设计模式

以上都不是。这只是重复执行相同操作的一种方法，有时是基于输入的变化。就此而言，这个概念比设计模式，代码重用甚至计算机要长得多。

您能否举一个现实世界中的示例为例，其中想到递归作为直接解决方案

析因可以解决斐波那契数列，树遍历和许多其他问题。从函数调用本身的意义上讲，递归不一定是实现这类事情的最佳方法。还有其他方法可能会更希望达到相同的效果（例如，堆栈和循环）。

在编写递归算法时，通常将问题的递归定义转换为代码。然后，您甚至不需要知道它将如何执行。

这就是函数编程中发生的事情。实际上，您指定的是什么（定义）而不是如何指定。换句话说，先定义基础，然后再用子问题定义问题。

例如考虑Factorial算法

• 定义基数：Factorial（1）= 1;
• 定义阶乘n：阶乘（n）= n *阶乘（n-1）;

然后，当您遇到问题时，您应该考虑是否可以递归定义它，如果可以递归定义它，您几乎已经解决了。

但是，任何递归函数都不应该是递归定义。您可以定义基础并将主要问题的解决方案与子问题的解决方案（定义）关联（定义）。但是对于这种关系，您可能需要一个过程。

一个例子是MergeSort在其中merge可以以涉及的定义或整个阵列到分类子阵列的排序的溶液势在必行过程。