functional-programming - 函数式编程中的多个源文件、目录结构和命名空间

Question

我惊讶地发现 Hacker News 的源代码只是一个包含简单函数定义列表的大文件。 Git Hub - news.arc

这是典型的函数式编程吗？在 OOP 项目中常见的潜在深层目录结构中的大量短文件中的源代码是否不常见？

FP 中的模块与 OOP 中的命名空间是一回事吗？

Answer 1

函数式编程语言 (FPL) 有很多种，而且它们非常不同。 Lisp 方言(如 Scheme、Common Lisp、Logo、Arc 等)也是如此。

通常它们不是围绕类(或类似概念)组织的，并且类通常不会与 namespace 混淆。

在一些面向对象的语言中，程序由许多类组成，类层次结构(或类似的东西)被映射到目录结构，每个类都是一个或多个文件。这导致软件系统由许多文件和一个以层次结构浏览这些文件/类的 IDE 组成。 (这与最初的 Smalltalk 不同，后者的代码由浏览器访问，而不是基于文件检索)。

例如，在 Common Lisp 中，类不是命名空间，方法也不附加到单个类(因为有多个方法)。有一个名为“package”的单独构造，它为 Lisp 符号提供 namespace 。典型的软件系统由捆绑了几个相关功能的文件组成。通常，较大的功能单元会获得自己的命名空间。

例如，一个图形工具包可能有几个命名空间:ui-backend、ui-user、ui-system、ui-drawing、ui-animation。 ui-drawing 命名空间可用于多个文件:ui-draw-2d-objects.lisp、ui-draw-3d-objects.lisp、ui-draw-macros.lisp 等。单个文件 ui-draw-2d-objects.lisp 将捆绑绘制 2d 对象(线、多边形、圆、位图等)所需的所有类、方法和变量。

然后开发系统负责提供导航。但导航通常不是分层的，而是基于搜索和检索符号。那么文件有多大并不重要。更重要的是，文件对正确的功能进行分组并在内部进行组织，以便可以通过某种方式识别相关的功能。

例如，如果我想识别所有矩形绘图函数，我会使用 REPL。

在 LispWorks 中，绘图原语位于“GP”或“GRAPHICS-PORTS”包中。然后我可以让 LispWorks 告诉我所有在包“GP”中包含“draw-rect”的符号。

CL-USER 10 > (apropos "draw-rect" "GP")
GRAPHICS-PORTS::%DRAW-RECTANGLE (defined)
GRAPHICS-PORTS::DRAW-RECTANGLE-BOUNDS (defined)
GRAPHICS-PORTS::%DRAW-RECTANGLES (defined)
GRAPHICS-PORTS::DRAW-RECTANGLES-BOUNDS (defined)
GRAPHICS-PORTS:DRAW-RECTANGLES (defined)
GRAPHICS-PORTS:DRAW-RECTANGLE (defined)

上面的列表告诉我，这些符号中的每一个都有定义的功能，带有单个冒号的符号是“导出的”。

然后我可以使用这些符号来查找更多信息:参数列表、源代码、文档等等。 Common Lisp 甚至提供标准函数，如 DOCUMENTATION、DESCRIBE 和 ED。

因此，这里的开发不是基于许多组织成某种类层次结构的小文件，而是基于模块和 namespace 的层次结构，每个 namespace 都捆绑了存储在一个或多个文件中的大量功能。然后，IDE 负责支持非分层浏览和搜索。