您对命令行的开发有什么看法，然后通过简单地调用命令行方法在事后添加GUI？
例如
W：\ todo AddTask“与John会面，重新：登录同行评审”“John的办公室”“2008-08-22”“14:00”
加载todo.exe并调用一个名为AddTask的函数，该函数执行一些验证并将会议引发到数据库中。
最后在屏幕上添加：
============================================================ Event: [meeting with John, re: login peer review] Location: [John's office] Date: [Fri. Aug. 22, 2008] Time: [ 2:00 PM] [Clear] [Submit] ============================================================
单击“提交”时，它将调用相同的AddTask函数。
是否考虑过：
附录：
我注意到这里的趋势是“由GUI和CLI可执行文件调用的共享库”。是否有一些令人信服的理由为什么它们必须分开，除了二进制文件本身的大小？
为什么不以不同的方式调用相同的可执行文件：
"todo /G"当您需要完整的图形界面时"todo /I"用于 todo.exe内的交互式提示（脚本等）"todo <function>"当你只想做一件事并完成它时。附录2：
有人提到“我[描述]的方式，每次GUI需要做某事时，你都需要生成一个可执行文件。”
同样，这不是我的意图。当我提到示例GUI称为“相同的AddTask函数”时，我并不是说GUI每次都称为命令行程序。我同意这将是非常讨厌的。我曾打算（参见第一个附录）这一切都在一个可执行文件中，因为它只是一个很小的例子，但我不认为我的措辞必然会排除共享库。
另外，我要感谢你们所有人的意见。这是一种不断涌现在我心中的东西，我很欣赏你的经验。
答案 0 :(得分：16)
我会使用链接到它的命令行应用程序来构建库。然后，您可以创建链接到同一个库的GUI。从GUI调用命令行会为每个命令生成外部进程，并且会对操作系统造成更大的破坏。
此外，使用库，您可以轻松地对功能进行单元测试。
但即使您的功能代码与命令行解释器分开，您也可以重新使用GUI的源代码而不必同时执行两种操作。
答案 1 :(得分：7)
将共享功能放在库中，然后为其编写命令行和GUI前端。这样，您的图层转换不依赖于命令行。
（另外，这种方式增加了另一个安全问题：GUI首先必须确保它是正在调用的正确的todo.exe吗？）
答案 2 :(得分：5)
几年前，乔尔写了一篇文章，将这种（“unix-style”）开发与GUI首先（“Windows风格”）方法进行了对比。他称之为Biculturalism。
我认为在Windows上将您的逻辑包装成.NET程序集将变得正常（如果还没有），然后您可以从GUI和PowerShell提供程序访问它们。这样你就可以获得两全其美的效果。
答案 3 :(得分：5)
我首先编写后端功能的技术，而不需要显式的UI（特别是当UI不是我的工作时，例如，我正在设计一个仍在设计阶段的Web应用程序）是写单元测试。
这样我甚至不需要编写一个控制台应用程序来模拟我的后端代码的输出 - 它都在测试中，并且与您的控制台应用程序不同，我不必抛弃测试的代码因为它们以后仍然有用。
答案 4 :(得分：3)
我认为这取决于您正在开发的应用程序类型。通过设计命令行，您可以快速了解Alan Cooper在The Inmates are Running the Asylum中所称的“实施模型”。结果是用户界面不直观且难以使用。
37signals还主张在Getting Real中首先设计您的用户界面。请记住，对于所有意图和目的，在大多数应用程序中，用户界面是程序。后端代码就是为了支持它。
答案 5 :(得分：2)
最好先从命令行开始，以确保功能正确。如果您的主要用户不能（或不会）使用命令行，那么您可以在工作之上添加GUI。
这将使您的应用更适合编写脚本以及限制前期Bikeshedding的数量，以便您更快地获得实际解决方案。
答案 6 :(得分：2)
如果您计划保留应用程序的命令行版本，那么我不会发现这样做的问题 - 这不是浪费时间。您仍将最终为命令行编写应用程序的主要功能，因此您将完成大部分工作。
我不认为这样做是一个很好的用户界面的障碍 - 你还有时间添加一个并且make是可用的等等。
我想这种工作方式只有在您打算让已完成的应用程序同时拥有命令行和GUI变体时才能真正起作用。很容易模拟UI并在其中构建您的功能，然后在以后美化UI。
同意Stu：您的基本功能应该在从命令行和GUI代码调用的库中。从UI调用可执行文件是运行时不必要的开销。
答案 7 :(得分：2)
@jcarrascal
我不明白为什么这会让GUI“变坏”？ 我的想法是，它会迫使你去思考“商业”逻辑究竟需要完成什么，而不必担心过于漂亮的东西。一旦你知道它应该/可以做什么，你就可以以最有意义的方式构建你的界面。
附注：不要开始单独的主题，但是对于问题的答案/评论的首选方法是什么？我考虑过这个，并编辑问题本身。
答案 8 :(得分：2)
我在我写的一个工具上做到了这一点，并且效果很好。最终结果是一个可编写脚本的工具，也可以通过GUI使用。
我同意你应该确保GUI易于使用和直观易用的观点，因此即使同时开发这两者也是明智的...一个小命令行功能，然后是GUI包装器以确保你是在直觉上做事。
如果你真的同时实现两者，结果是一个可以自动使用的应用程序，我认为这对高级用户来说非常强大。
答案 9 :(得分：1)
有点取决于你对程序的目标，但是我不时地这样做 - 代码更快，更容易调试，更容易编写快速和脏的测试用例。只要我正确地构建我的代码，我就可以在没有太多工作的情况下返回并在以后使用GUI。
对于那些暗示这种技术会导致可怕的，无法使用的用户界面的人：你是对的。编写命令行实用程序是设计GUI的一种可怕方法。请注意，每个人都在考虑编写不是 CLUI的UI - 不要将其原型化为CLUI。
但是，如果您正在编写本身不依赖于UI 的新代码，那就去吧。
答案 10 :(得分：1)
出于几个原因，我不会这样做。
设计
GUI和CLI是用于访问底层实现的两个不同接口。它们通常用于不同的目的（GUI用于实时用户，CLI通常通过脚本访问）并且通常可以具有不同的要求。将两者结合在一起并不是明智的选择，必然会给你带来麻烦。
性能：
您描述事物的方式，每次GUI需要时都需要生成可执行文件。这简直太丑了。
执行此操作的正确方法是将实现放在由CLI和GUI调用的库中。
答案 11 :(得分：1)
更好的方法可能是将逻辑开发为具有良好定义的API的lib，并且在开发阶段，没有接口（或硬编码接口），那么您可以稍后调用CLI或GUI
答案 12 :(得分：1)
John Gruber有一篇关于为不是为一个程序设计的程序添加GUI的概念的好文章：Ronco Spray-On Usability
摘要：它不起作用。如果可用性从一开始就没有被设计到应用程序中，那么以后添加它比任何人都愿意做的工作更多。
答案 13 :(得分：1)
如果您的开发正确，那么稍后在项目中切换到GUI应该相对容易。问题是，要做到这一点有点困难。
答案 14 :(得分：1)
我通常从一个类库和一个单独的，非常糟糕的基本GUI开始。由于命令行涉及解析命令行，我觉得我增加了很多不必要的开销。
作为奖励，这提供了类似MVC的方法，因为所有“真实”代码都在类库中。当然，在稍后阶段，将库与真实GUI一起重构为一个EXE也是一种选择。
答案 15 :(得分：0)
执行您作为Web服务公开的程序。然后执行gui和命令行来调用相同的Web服务。这种方法还允许您制作web-gui，并为外联网合作伙伴提供SaaS功能，和/或更好地保护业务逻辑。
这也使您的程序更容易参与SOA环境。
对于网络服务，不要过火。做yaml或xml-rpc。保持简单。
答案 16 :(得分：0)
@Maudite
命令行应用程序将预先检查params而GUI不会 - 但他们仍然会检查相同的参数并将它们输入到一些通用工作器函数中。
仍然是同一个目标。我没有看到影响GUI质量的命令行版本。
答案 17 :(得分：0)
除Stu所述之外，拥有共享库还允许您从Web应用程序中使用它。甚至是IDE插件。
答案 18 :(得分：0)
命令行工具生成的事件少于GUI应用程序，通常在启动之前检查所有参数。这将限制你的gui，因为对于gui来说，在你的程序运行或之后请求params更有意义。
如果你不关心GUI，那就不用担心了。如果最终结果是gui，请首先制作gui，然后执行命令行版本。或者你可以同时处理这两个问题。
- 大规模编辑 -
在我目前的项目上花了一些时间之后，我觉得我已经从我之前的回答中走了一圈。我认为最好首先执行命令行，然后在其上包装一个gui。如果你需要的话，我想你可以在之后成为一个伟大的gui。首先执行命令行，首先获取所有参数，这样在执行UI / UX时就不会出现任何意外（直到需求发生变化）。
答案 19 :(得分：0)
为什么这样做不是一个好主意有几个原因。已经提到了很多，所以我只想坚持一个具体的观点。
命令行工具通常根本不是交互式的，而GUI则是。这是一个根本的区别。例如，这对于长期运行的任务来说是痛苦的。
您的命令行工具最多会打印出某种进度信息 - 换行符，文本进度条，一堆输出，......任何类型的错误都只能输出到控制台。
现在你要打一个GUI，你做什么？解析长时间运行的命令行工具的输出？在该输出中扫描WARNING和ERROR以打开一个对话框？
充其量，大多数UI以这种方式构建，只要命令运行就会抛出一个脉动繁忙的栏，然后在命令退出时显示成功或失败对话框。遗憾的是，这就是许多UNIX GUI程序被抛在一起的方式，这使得它成为一种糟糕的用户体验。
这里的大多数回复者都说你应该将程序的实际功能抽象到库中，然后同时编写命令行界面和GUI。您的所有业务逻辑都应该在您的库中，并且UI（是的，命令行是UI）应该只执行业务逻辑和UI之间的接口所需的任何操作。
命令行的UI太差，无法确保您的库的开发足够好以便以后使用GUI。您应该从一开始就开始，或者从GUI编程开始。将命令行界面添加到为GUI开发的库中很容易，但反过来要困难得多，正是因为GUI需要的所有交互功能（报告，进度，错误对话框，i18n，... ）
答案 20 :(得分：0)
这正是我最重要的编码实现之一，我希望更多人采取这种方法。
只是一个小小的澄清：GUI不应该是命令行的包装器。相反，应该能够从GUI或命令行驱动程序的核心。至少在开始时和基本操作。
什么时候这个好主意？
当您想确保您的域实现独立于GUI框架时。您希望将围绕框架而非编码到框架
中这什么时候不错？
如果您确定您的框架永远不会死亡