35

我应该如何为程序而不是库命名我的 Haskell 模块，并将它们组织成层次结构？

我正在制作一个名为 Luminosity 的光线追踪器。首先我有这些模块：

Vector Colour Intersect Trace Render Parse Export

每个模块本身都很好，但我觉得这缺乏组织。

首先，我将每个模块都放在 下 Luminosity，例如Vector现在Luminosity.Vector（我假设这是 haskell 程序的标准？）。

然后我想：Vector和Color是独立的，可以复用，所以应该分开。但是它们太小了，不能变成图书馆。

他们应该去哪里？已经有（在hackage上） a Data.Vectorand Data.Colour，所以我应该把它们放在那里吗？或者这会导致混淆（即使我将它们与其他本地进口组合进口）？如果不存在，应该是Luminosity.Data.Vector还是Data.Luminosity.Vector？我很确定我已经看到两者都使用过，尽管也许我只是碰巧看到了一个使用非常规结构的项目。

我还有一个简单的 TGA 图像导出器 ( Export)，它可以独立于 Luminosity。看起来正确的位置应该是Codec.Image.TGA，但同样，应该Luminosity在某个地方，如果是，在哪里？

如果Haskell 项目的结构或其他一些 wiki 解释了这一点，那就太好了。

4

2 回答 2

21

除非你的程序真的很大，否则不要按层次组织模块。 为什么不？因为尽管计算机擅长等级制度，但人却不擅长。人们擅长有意义的名字。如果您选择好的名称，您可以轻松地在一个平面名称空间中处理 150 个模块。

我觉得 [a flat name space] 缺乏组织。

等级组织本身并不是目的。为了证明将模块分成层次结构的合理性，您需要一个原因。好的理由往往与信息隐藏或重用有关。当您引入信息隐藏时，您就完成了库设计的一半，而当您谈论重用时，您实际上是在构建库。将一个大程序变身为“小程序加库”是软件进化的一个好策略，但看起来你才刚刚开始，你的程序还不够大，无法以这种方式进化。

这些问题在很大程度上与您使用的编程语言无关。我推荐阅读 David Parnas 关于产品线和程序系列的一些著作，以及 Matthias Blume 的被低估的论文Hierarchical Modularity。这些作品将为您提供一些关于等级何时开始服务于目的的更具体的想法。

于 2012-07-21T20:35:58.520 回答
14

首先我把每个模块都放在Luminosity

我认为这是一个很好的举措。它向正在阅读代码的任何人阐明这些模块是专门为该Luminosity项目制作的。

如果您编写模块的目的是模拟或改进现有库，或者填补您认为缺少特定通用库的空白，那么在极少数情况下，请删除前缀并通用命名。有关这方面的示例，请参阅管道包的导出方式Control.Monad.Trans.Free，因为无论出于何种原因，作者对 Free monad 的现有实现都不满意。

然后我想，Vector和Color是非常独立的，可以重复使用，所以应该分开。但是它们太小了，无法分离到一个库中（分别为 125 行和 42 行）。他们应该去哪里？

如果您不制作单独的库，则可能将它们留在Luminosity.Vectorand Luminosity.Colour。如果您确实创建了单独的库，请尝试向这些库的目标受众发送电子邮件，看看其他人认为这些库应该如何命名和分类。是否将它们拆分为单独的库完全取决于您以及您认为这些单独的库可能为其他人提供多少好处。

于 2012-07-22T03:02:19.850 回答