architecture - 设计控制台应用程序时的架构考虑？

Question

我最近编写了一个控制台应用程序，我在设计它的许多方面都经历了很多痛苦，特别是在 C# 中，因为它具有纯 OO 范式。我面临的问题包括从如何传递选项到如何将问题返回到入口点类等等。

我的问题是:你们中的任何人都知道 OO 范式中控制台应用程序的良好设计，以便我可以从中学习吗？好的实现代码是特别是 欢迎。

编辑:我不追求命令行 API，而是追求良好的设计原则，尤其是我可以从中学习的良好实现。

编辑 2:应用程序中有简单的用户交互，但它不是成熟的 CLI/REPL 类型。或多或少将其视为 TeX 命令。有趣的是，即使有很好的理论(与 X 没有什么不同，使用模式 Y，你应该知道 OO 原理......[你的计算机科学教授会很自豪!])，没有真正的代码我可以拿看看这些概念在行动。同样，在纯 OO 范例中，我应该在哪里寻找(代码!)一个好的命令行应用程序？

Answer 1

听起来好像您正在构建一个接口(interface)，该接口(interface)在每次调用时执行几个不同的操作之一。我不确定您指的是“命令行”应用程序(执行一项操作，然后退出)还是 CLI 应用程序(显示提示并重复响应用户输入)。一般来说，前者的构建会比后者简单得多；我认为只有在您的应用程序需要一些通过多个命令演变的持久状态时才有意义使用 CLI。如果您正在处理这样的事情，那么 alphazero 是正确的——您可能应该了解 REPL 并复制一个好的。

无论如何，执行的操作将取决于命令行上传递的参数，所以我将就这部分进行头脑 Storm ......

将应用程序视为一组不同的“命令”对象是明智的，每种类型的操作都有一个。因此，应用程序的入口点应该是某种 CommandLineDispatcher 对象，它将请求分派(dispatch)到适当的 Command 对象。

为了模块化，调度程序应该配置一个抽象的映射(例如，一个哈希表)，以将每个命令标记(通常是命令行字符串的第一个单词)与处理它的命令对象相关联。调度程序还可以处理常见的选项解析，可能使用一些现成的“getopts”库来完成繁重的工作。

简单来说，每个 Command 对象都可以实现一个一致的接口(interface)来完成它的工作；也许是这样的:

public void execute(List<String> args)

这样，入口点调度程序只会找到正在请求的命令，并且 executes它。

关于错误处理: execute()方法可能只是抛出一个异常来传达错误......异常可以被调度程序捕获和处理，或者只是简单地记录到屏幕上。或者，失败的命令可能会调用一些共享的 usage将错误消息与一般说明结合起来的功能。我认为不必像您建议的那样使“入口点”意识到问题；如果您需要强大的错误处理(例如，用于日志记录或警报功能)，这似乎属于可以提供给 Command 对象的单独组件。

一般来说，命令行应用程序与响应用户输入的任何其他应用程序没有什么不同——您需要一个调度程序来解析和路由输入，以及处理程序(又名“ Controller ”)来执行支持的操作。如果您需要其他服务(日志记录、警报、数据库连接等)，您最好创建单独的组件来隔离此逻辑并使用干净的接口(interface)公开它。