SlowCoach asked:
I guess if you don't enter a letter, things will go horribly wrong and I probably have a couple of casting issues, but how do you envisage enumerators or constants as helping? I would have thought that having declared them in this manner, I'd still need a select case statement or IF, ELSEIF Else statements? Please could you explain?
Please see my comment to solution one, in response to this question. It thought it should be quite obvious.
It's not really about having "ifs" or "switched". But…
Even those "
switch
" of "
if
", strictly speaking, does not have to be there. Again, this is all mostly the matter of maintainability of code and the ways you can avoid repeating the same things again and again. Do you understand that there are generics? dictionaries and other data structures, other means of abstraction. As a rule of thumb, if you see too much if "ifs" and "switched", this is a good indication that you are doing something wrong and should think about some better ways, more abstracted. Let's take your case. How can you trigger some actions in response to some entered string/character? Easy! You can create dictionary, with first generic parameter, key, to become a string or a char, and the second one, value, to become a delegate instance of certain type. It's enough to build such mechanism just once. My article on the topic explains it all:
Dynamic Method Dispatcher.
Now, I would suggest you to make one more step and think of something not really related to this issue. Why do you have those "A", "B" and "C" keys at all? Because you try to create an interactive console-based application. Is it a good idea? As a rule of thumb, but. Look at the well-known console-only applications. Almost all of them have no interactive input at all (some exclusion apply, but there are very few of them). Why so? First of all, because such applications are very inconvenient. Make a little mistake and you have to enter data again. Instead, such applications are usually based on command-line parameters. The command line can be relatively long, but when you do a mistakes, the cost of mistake is very low: most applications starting other applications with command line, command interpreters (such as CMD.EXE, but there are a lot more "commanders") always give you the possibility to quickly repeat last commands. You just fix a character or two, if you make a mistake. My other article suggests a very convenient, well maintainable, simple and easy-to-use way of parsing command line:
Enumeration-based Command Line Utility (enumerations again, by the way). Interactive console-based applications are just not needed, they are too dreadful to be convenient.
Finally, for more complicated input, the graphical UI can be the best.
—SA