Question

I have recently programmed a console application and I’ve experienced a lot of pain in designing it in many aspects, particularly in C#, given its pure OO paradigm. Questions I have faced include anything from how to pass the options to how to return problems to the entry point class, among many, many others.

My question is: would any of you know of good designs of console applications in an OO paradigm so I can learn from them? Code of good implementations is particularly welcome.

EDIT: I’m not after command-line APIs, but after good design principles, and, in particular, good implementations I could learn from.

EDIT 2: There is simple user interaction in the application, but it is not a full-fledged CLI/REPL sort. Think of it as the TeX command, more or less. Interestingly, even though there is good theory floating around (no different than X, use pattern Y, you should know OO principles…[your computer science professor would be so proud!]), there is no real code I can take a look at to see these concepts in action. Again, where should I look (code!) for a good command line application in a pure OO paradigm?

Answer 1

It sounds as if you’re building an interface that performs one of several distinct operations with each invocation. I’m not sure if you’re referring to a “command-line” application (which does one action, then exits) or a CLI application (which displays a prompt and responds repeatedly to user input). In general, the former will be much simpler to build than the latter; I think it only makes sense to use a CLI if your application requires some persistent state that evolves over multiple commands. If you are tackling something like this, then alphazero is correct — you should probably learn about REPLs and copy a good one.

In any case, the operation performed will depend on the arguments passed on the command-line, so I’ll brainstorm about that part…

It’s sensible think of the application as a set of distinct “Command” objects, one for each type of operation. The entry-point to the application should thus be a some sort of CommandLineDispatcher object that dispatches requests to the appropriate Command object.

To be modular, the dispatcher should be configured with an abstracted mapping (eg, a Hashtable) to associate each command token (usually the first word of the command-line string) to the Command object that handles it. The dispatcher may also handle common options-parsing, probably using some off-the-shelf “getopts” library to do the heavy lifting.

To start simple, each Command object could implement a consistent interface for doing its work; maybe something like this:

public void execute(List<String> args)

This way, the entry-point dispatcher just finds the Command being requested, and executes it.

Regarding error-handling: the execute() method might just throw an exception to communicate errors… Exception could be caught and processed by the dispatcher, or simply logged to the screen. Alternatively, failing Commands could invoke some shared usage function to combine an error message with general instructions. I don’t think the “entry point” should necessarily be made aware of problems as you suggest; if you need robust error-handling (eg, for logging or alerting capabilities), this seems like it belongs in a separate component that could be provided to the Command object.

In general, a command-line application is no different than any other application that responds to user input — you’ll need a dispatcher to parse and route the input, and handlers (aka “controllers”) to execute the supported operations. If you need other services (logging, alerting, database connectivity, etc), you’ll do well to create separate components to isolate this logic and expose it with clean interfaces.