ide - 为什么我们不使用函数数据库而不是包/库？

Question

为什么我们不使用集中式函数数据库，而不是实际的包/库概念？我可以看到很多优点。

更容易成长(任何人都可以发送他的小功能，而不是维持大型

所需的工作)

可分析。统计和图论工具可用于分析和分类数据库。

终极生产力工具。假设您的任务是将文件夹中的所有图像转换为黑白图像。你可以用谷歌搜索和安装你的语言的图像处理和操作系统包，然后学习并搜索正确的功能。整个过程可能需要一天时间。或者您可以在上述全局数据库中搜索“打开文件夹中的图像文件”功能、“将图像转换为黑白”功能和“保存图像”功能，整个过程可能需要一分钟。 现在把它推广到任何编程任务，你就会明白为什么我觉得这很重要。

为什么不采用这个概念？

Answer 1

这是一个有趣的想法。我认为问题的关键在于:一个设计良好的库(或一组库)是连贯的，因为它会仔细选择一小组函数、数据结构和其他约定。这就是让程序员理解、使用和重用它的原因。

一个庞大的函数数据库似乎是在尝试使一个不连贯的、未经设计的大量函数在同样的意义上可重用。但我不认为问题的难点在于首先找到相关功能:我担心任意技术选择的纯粹组合爆炸(即使在中等简单的任务中也是如此)会挫败大多数直接重用的尝试(与类似伪代码的灵感相反)。

以您的“在文件夹中打开图像”示例查询为例，并考虑可能的目标函数如何:

识别文件夹:目录句柄、字符串或十几个“路径”数据结构之一

选择特定图像:字符串、模式匹配或众多交互式 UI 选项之一

处理图像格式:例如 GIF、JPG、PNG 或各种多语言图像加载器框架

加载图像:无条件地，标题/元数据，然后是正文，按图 block ，按行或其他

表示图像:它使用什么数据结构来存储加载的图像？

使用异常、错误或中间决策点

程序员可以轻松处理其中一些可能性(假设函数已正确记录)。有些可能是可修补的(例如，通过找到另一个函数来从提供的帧缓冲区格式转换为您可以使用的格式)。但其他人具有重量级的技术含义。交互式 UI 文件选择器需要使用特定的 UI 框架。多语言图像加载器功能可以拉入数十个图像库，并将您提交给它的内存管理方案。

换句话说:“为重用而设计”几十年来一直是软件工程师充满希望的座右铭，而我们的最大努力只取得了适度的成功。然而，长期的经验告诉我们这句话中隐含的教训:没有“设计”部分，“重用”就没有机会。