什么是“工具包设计”？

Question

“工具包设计”意味着什么?为特定任务/项目设计工具包的基本步骤是什么？

它出现在一项任务描述中，其中说：“该任务处理为实现在这里插入一些开发任务而使用的各种工具的详细规范的设计。”

所以我所理解的是:它需要设计和提供一个工具包的规范，它将用于执行一些特定的任务。但是工具包设计是如何完成的呢？

搜索谷歌几乎没有任何有意义的结果。他们主要是关于“设计工具包”，这不是我想要的。

例如，这个家伙在他以前的一些项目http://logonpro.com/resume.doc中设计了一个软件工具包。

Answer 1

如果你问这个问题，你不应该开始设计工具包;-)

撇开玩笑，我的看法如下(国产，没有大牌)。

你必须建立一个软件，这将解决一个特定的任务。您有一些关于不同数据对象、相关业务逻辑、工作流、外观、性能等的规范。应用程序在特定环境中必须满足的需求(桌面或服务器、操作系统、框架、.)

然而，为了实现这个目标，您可能会花费更多的时间在“内务管理”上，而不是实现实际的算法、工作流等:您将存储和读取持久数据、进程配置信息、命令行参数、脚本、管理GUI与业务逻辑之间的通信、处理错误。在更复杂的场景(如游戏开发)中，您花费大量的时间不是在编码上，而是只花在构建配置(如设计一个级别地图、参与者等)、启用脚本和编写脚本、.有时候，创建独立的助手应用程序来做这样的事情是有益的。后者就是我所说的“工具包层”：不是直接指定为请求，而是需要它们来完成您的工作。您设计的工具包层越好，它所需的工作就越多，但是最后，当您必须解决任务时，工具会使它变得非常简单。

简单地说:你可以一个一个地解决你的任务--或者提取相似之处，解决它们一次，而解决一个“真实”任务意味着在特定的环境中使用公共层。问题:公共层是

• 本质上更复杂，因为它应该回答“任何”问题，而不是“一个”，
• 很难修改，因为很多其他代码都依赖它们，
• 当它破裂的时候，它可能会撞上几乎任何东西。

很好的理论，很难的东西。

如果您对当前任务背后的工具包没有远见，我认为您不应该设计它。用一种很好的、面向对象的方式来设计应用程序:接口、抽象类、共享的助手组件。后者将是此应用程序的“工具包层”。如果您设计得很好，这一层将帮助您在截止日期前向应用程序添加“最后一个新功能”或组件。如果您能够很好地估计这种情况下所需的时间，那么您的工具包是很好的。

..。如果你在这个工具包上生活了20年，你就不会看到应用程序，只有工具包层。这就是为什么我创建了一个带有公共持久层的自动JSON序列化程序，并为我的第一个iOS应用程序创建了一个数据绑定GUI工具包。我不能用另一种方式(和目标C/可可岩).