21

您对首先开发命令行，然后通过简单地调用命令行方法添加 GUI 有什么看法？

例如。

W:\ todo AddTask "与 John 会面，re: login peer review" "John's office" "2008-08-22" "14:00"

加载todo.exe并调用一个被调用的函数，该函数AddTask进行一些验证并将会议放入数据库中。

最终，您为此添加了一个屏幕： 

==================================================== ==========

事件：[与约翰会面，回复：登录同行评审]

地点：[约翰的办公室]  

日期：[星期五。2008 年 8 月 22 日]  

时间：[下午 2:00]

[清除] [提交]

==================================================== ==========

当您单击提交时，它会调用相同的 AddTask 函数。

是否考虑过：

  • 编码的好方法
  • 只为新手
  • 太可怕了！

附录：

我注意到“由 GUI 和 CLI 可执行文件调用的共享库”的趋势。除了二进制文件本身的大小之外，是否有一些令人信服的理由必须将它们分开？

为什么不以不同的方式调用相同的可执行文件：

  • "todo /G" 当您想要完整的图形界面时
  • "todo /I"用于（脚本等）中 的交互式提示todo.exe
  • "todo <function>"当您只想做一件事并完成它时，它就很老了。

附录 2：

有人提到“[我]描述事物的方式，每次 GUI 需要做某事时，你 [将] 需要生成一个可执行文件。”

同样，这不是我的意图。当我提到示例 GUI 调用“相同的AddTask功能”时，我并不是指 GUI 每次都调用命令行程序。我同意那将是非常讨厌的。我原本打算（参见第一个附录）将所有这些都保存在一个可执行文件中，因为这是一个小例子，但我认为我的措辞不一定排除共享库。

另外，我要感谢大家的意见。这件事一直在我脑海中浮现，我很欣赏你的经验。

4

21 回答 21

16

我会使用链接到它的命令行应用程序构建一个库。之后，您可以创建一个链接到同一个库的 GUI。从 GUI 调用命令行会为每个命令生成外部进程，并且对操作系统的破坏性更大。

此外，使用库，您可以轻松地对功能进行单元测试。

但是，即使您的功能代码与命令行解释器是分开的，您也可以将源代码重新用于 GUI，而无需同时使用这两种代码来执行操作。

于 2008-08-21T01:08:37.000 回答
7

将共享功能放入库中，然后为其编写命令行和 GUI 前端。这样，您的图层转换就不会绑定到命令行。

（此外，这种方式增加了另一个安全问题：GUI 不应该首先确保它是被调用的正确的 todo.exe 吗？）

于 2008-08-20T22:31:17.097 回答
5

几年前，Joel 写了一篇文章，将这种（“unix 风格”）开发与 GUI 优先（“Windows 风格”）方法进行了对比。他称之为双文化主义。

我认为在 Windows 上，将您的逻辑包装到 .NET 程序集中（如果还没有的话）将变得很正常，然后您可以从 GUI 和 PowerShell 提供程序访问这些程序集。这样你就可以两全其美了。

于 2008-08-20T22:32:37.060 回答
5

我在不需要显式 UI 的情况下首先编写后端功能的技术（尤其是当 UI 还不是我的工作时，例如，我正在设计一个仍处于设计阶段的 Web 应用程序）是编写单元测试。

这样，我什至不需要编写控制台应用程序来模拟我的后端代码的输出——这一切都在测试中，并且与您的控制台应用程序不同，我不必丢弃测试代码，因为它们仍然以后有用。

于 2008-08-20T23:02:23.980 回答
3

我认为这取决于您正在开发的应用程序类型。为命令行进行设计可以让您快速了解 Alan Cooper 在The Inmates are Running the Asylum中所说的“实施模型” 。结果是用户界面不直观且难以使用。

37signals 还提倡在Getting Real中首先设计您的用户界面。请记住，出于所有意图和目的，在大多数应用程序中，用户界面就是程序。后端代码只是为了支持它。

于 2008-08-20T22:37:57.923 回答
2

最好先从命令行开始，以确保功能正确。如果您的主要用户不能（或不会）使用命令行，那么您可以在您的工作之上添加一个 GUI。

这将使您的应用程序更适合编写脚本并限制前期Bikeshedding的数量，以便您可以更快地获得实际解决方案。

于 2008-08-20T22:34:25.840 回答
2

如果您打算保留应用程序的命令行版本，那么我认为这样做没有问题 - 这不会浪费时间。您最终仍会为命令行编写应用程序的主要功能，因此您将完成大量工作。

我不认为以这种方式工作会成为一个好的 UI 的障碍 - 你仍然有时间添加一个并使其可用等。

我想这种工作方式只有在你打算让你完成的应用程序同时具有命令行和 GUI 变体时才真正起作用。模拟 UI 并将您的功能构建到其中然后美化 UI 很容易。

同意 Stu：您的基本功能应该在从命令行和 GUI 代码调用的库中。在运行时从 UI 调用可执行文件是不必要的开销。

于 2008-08-20T22:37:18.533 回答
2

@jcarrascal

我不明白为什么这必须使 GUI “坏”？
我的想法是，它会迫使您考虑“业务”逻辑实际上需要完成什么，而不必过多担心事情是否漂亮。一旦您知道它应该/可以做什么，您就可以围绕它以最有意义的任何方式构建您的界面。

旁注：不要开始一个单独的主题，但解决问题的答案/评论的首选方式是什么？我考虑了这一点，并编辑了问题本身。

于 2008-08-20T22:37:52.540 回答
2

我正是在我编写的一个工具上做到了这一点，而且效果很好。最终结果是一个可编写脚本的工具，也可以通过 GUI 使用。

我确实同意您应该确保 GUI 易于使用且直观的观点，因此甚至同时开发两者可能是明智之举......一个小的命令行功能，然后是一个 GUI 包装器，以确保您正在做直观的事情。

如果你真的要平等地实现两者，那么结果就是一个可以以自动化方式使用的应用程序，我认为这对于高级用户来说非常强大。

于 2008-08-20T22:48:47.537 回答
1

有点取决于您对程序的目标，但是是的，我不时这样做-编码更快，更容易调试，并且更容易编写快速而肮脏的测试用例。只要我正确地构建了我的代码，我就可以稍后返回并添加一个 GUI，而无需太多工作。

对于那些暗示这种技术会导致可怕的、无法使用的 UI 的人：你是对的。编写命令行实用程序是设计 GUI 的一种糟糕方法。请注意，每个人都在考虑编写不是CLUI 的 UI - 不要将其原型化为 CLUI。

但是，如果您正在编写本身不依赖于 UI 的新代码，那就去做吧。

于 2008-08-20T22:32:02.290 回答
1

我通常从一个类库和一个单独的、非常糟糕的基本 GUI 开始。由于命令行涉及解析命令行，我觉得我增加了很多不必要的开销。

作为奖励，这提供了一种类似 MVC 的方法，因为所有“真实”代码都在类库中。当然，在后期，将库与真正的 GUI 一起重构为一个 EXE 也是一种选择。

于 2008-08-20T23:08:42.827 回答
1

如果您的开发正确，那么稍后在项目中切换到 GUI 应该相对容易。问题是要做到这一点有点困难。

于 2008-08-20T23:47:25.713 回答
1

约翰·格鲁伯 (John Gruber) 发表了一篇关于将 GUI 添加到不是为某个程序设计的程序的概念的好帖子：Ronco Spray-On Usability

总结：没用。如果从一开始就没有将可用性设计到应用程序中，那么以后添加它比任何人都愿意做的工作要多。

于 2008-08-20T23:52:25.670 回答
1

更好的方法可能是将逻辑开发为具有明确定义的 API 的库，并且在开发阶段没有接口（或硬编码接口），然后您可以稍后编写 CLI 或 GUI

于 2008-08-21T00:30:10.663 回答
1

出于几个原因，我不会这样做。

设计：

GUI 和 CLI 是用于访问底层实现的两个不同接口。它们通常用于不同的目的（GUI 用于实时用户，CLI 通常通过脚本访问）并且通常具有不同的要求。将两者结合在一起不是一个明智的选择，并且必然会给您带来麻烦。

表现：

按照您描述事物的方式，每次 GUI 需要执行某些操作时，您都需要生成一个可执行文件。这简直丑陋。

执行此操作的正确方法是将实现放入由 CLI 和 GUI 调用的库中。

于 2008-08-21T13:19:01.410 回答
0

命令行工具生成的事件少于 GUI 应用程序，通常在启动前检查所有参数。这将限制您的 gui，因为对于 gui，在程序运行时或之后请求参数可能更有意义。

如果您不关心 GUI，请不要担心。如果最终结果是 gui，请先制作 gui，然后再制作命令行版本。或者你可以同时处理这两个问题。

--大量编辑--

在我目前的项目上花了一些时间之后，我觉得我已经从我之前的回答中走出来了。我认为最好先执行命令行，然后在其上包装 gui。如果你需要，我认为你可以在之后制作一个很棒的 gui。通过首先执行命令行，您首先获取所有参数，因此在执行 UI/UX 时不会有任何意外（直到需求发生变化）。

于 2008-08-20T22:51:02.710 回答
0

@Maudite

命令行应用程序将预先检查参数，而 GUI 不会 - 但他们仍将检查相同的参数并将它们输入到一些通用工作函数中。

还是一样的目标。我没有看到影响 GUI 质量的命令行版本。

于 2008-08-20T23:02:07.333 回答
0

执行您公开为 Web 服务的程序。然后执行 gui 和命令行来调用相同的 Web 服务。这种方法还允许您制作 web-gui，还可以将功能作为 SaaS 提供给外联网合作伙伴，和/或更好地保护业务逻辑。

这也使您的程序能够更轻松地参与 SOA 环境。

对于网络服务，不要过火。做 yaml 或 xml-rpc。把事情简单化。

于 2008-08-20T23:59:25.183 回答
0

除了Stu所说的之外，拥有一个共享库还可以让您在 Web 应用程序中使用它。甚至来自 IDE 插件。

于 2008-08-21T02:43:00.657 回答
0

这样做不是一个好主意有几个原因。已经提到了很多，所以我只坚持一个具体点。

命令行工具通常根本不是交互式的，而 GUI 是。这是一个根本的区别。例如，这对于长时间运行的任务来说是痛苦的。

您的命令行工具最多只能打印出某种进度信息——换行符、文本进度条、一堆输出……任何类型的错误它只能输出到控制台。

现在你想在上面加上一个 GUI，你会怎么做？解析长时间运行的命令行工具的输出？扫描该输出中的 WARNING 和 ERROR 以弹出对话框？

充其量，只要命令运行，大多数以这种方式构建的 UI 都会抛出一个脉动的繁忙栏，然后在命令退出时向您显示成功或失败对话框。可悲的是，这就是许多 UNIX GUI 程序组合在一起的方式，这使得它成为一种糟糕的用户体验。

这里的大多数回复都是正确的，您可能应该将程序的实际功能抽象到库中，然后同时为其编写命令行界面和 GUI。您的所有业务逻辑都应该在您的库中，并且任何一个 UI（是的，命令行就是一个 UI）应该只执行您的业务逻辑和 UI 之间的接口所必需的任何事情。

命令行对于 UI 来说太差了，无法确保您开发的库足以供以后使用 GUI。您应该从一开始就开始，或者从 GUI 编程开始。将命令行界面添加到为 GUI 开发的库中很容易，但反过来就困难得多，这正是因为 GUI 需要的所有交互功能（报告、进度、错误对话框、i18n、... )

于 2008-08-25T22:08:51.447 回答
0

这正是我对编码最重要的认识之一，我希望更多的人会采用这种方法。

只是一个小的澄清：GUI 不应该是命令行的包装器。相反，应该能够从 GUI 或命令行驱动程序的核心。至少在开始时只是基本操作。

什么时候是个好主意？

当您想确保您的域实现独立于 GUI 框架时。您想围绕框架编写代码而不是进入框架

什么时候这是个坏主意？

当你确定你的框架永远不会消亡时

于 2017-01-14T08:14:56.400 回答