设计控制台应用程序时的体系结构考虑？

Question

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

我的问题是:你们中有谁知道在OO范例中控制台应用程序的好设计，这样我就可以从中学习了吗？好的实现代码是，特别是欢迎的。

编辑：--我不是追求命令行API，而是遵循良好的设计原则，特别是我可以从中学习的良好实现。

编辑2:应用程序中有简单的用户交互，但它不是一个成熟的CLI/REPL排序。可以把它看作是TeX命令，或多或少。有趣的是，尽管到处都有好的理论(与X一样，使用模式Y，你应该知道OO principles...your计算机科学教授会很自豪！)，没有真正的代码，我可以看看这些概念的行动。再说一遍，我应该在哪里查找(代码！)对于一个好的命令行应用程序来说，在纯OO范式中？

Answer 1

听起来好像您正在构建一个接口，在每次调用中执行几个不同的操作之一。我不确定您指的是“命令行”应用程序(它执行一个操作，然后退出)还是CLI应用程序(它显示提示并重复响应用户输入)。一般来说，前者的构建要比后者简单得多；我认为，只有当应用程序需要经过多个命令演化的持久状态时，使用CLI才有意义。如果你正在处理类似的问题，那么字母零是正确的--你应该学习REPL，并复制一个好的。

在任何情况下，执行的操作将取决于在命令行上传递的参数，因此我将对此部分进行头脑风暴.

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

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

为了简单起见，每个Command对象都可以实现一个一致的接口来完成它的工作；也许如下所示：

public void execute(List<String> args)

这样，入口点调度员就会找到被请求的命令，并对其进行executes。

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

一般来说，命令行应用程序与响应用户输入的任何其他应用程序没有什么不同--您将需要一个dispatcher来解析和路由输入，需要处理程序(也称为“控制器”)来执行所支持的操作。如果您需要其他服务(日志记录、警报、数据库连接等)，那么最好创建单独的组件来隔离这个逻辑并使用干净的接口公开它。

Answer 2

当涉及到诸如日志、错误和异常处理、安全性等关键交叉关注点时，控制台应用程序与常规的win窗体或web应用程序没有任何不同之处。

话虽如此，你能否详细说明我们的问题，即它们的主要关切领域在哪里？

您可以从微软的App体系结构指南中提取许多模式。

Answer 3

在Java中，我经常使用Apache，我在googled上搜索了“CLIfor.NET”，但它似乎还不是任何实现。可能对您阅读Java方法来接收控制台参数是有用的。

对于应用程序的体系结构，它应该与您在Web应用程序中使用的体系结构没有太大的不同，不同之处在于控制台是表示层的接口。也许您可以定义一些“ConsoleControllers”来将模型从业务层接收到控制台，反之亦然。将每个用户的输入视为请求;)。