Topic awaiting preservation: Java - Writing a command line interface

In what little spare time I have I'm working on a swing app (fairly simple drawing program), and I'd like there to be a command line interface to it. I've got the basic layout of something that could work so far (100+ if-else-if statements, nested 5 deep in spots), but there's got to be a better/faster/more organized/more efficient/etc way to do it.
I've almost kinda halfway worked something out in my head, but I can't put it into a single, coherent thought, much less into code.

So would someone mind enlightening me, or at least pointing me in the right direction?

LF

-- Curiosity may have killed the whole cat, but Schrodinger only killed half --

How about using switch statements? Much cleaner.....

/* Sure, go ahead and code in your fancy IDE. Just remember: it's all fun and games until someone puts an $i out */

That'd be a step in the right direction, but it still seems to me that there should be a better way to handle it...

Maybe implement a rules engine like Jess? Looking through this essay, the only reasons to not use one are because the decisions involved in my algorithm are static and this is a one-shot deal (not a lot of maintenance once it's finished). However, are the other reasons (1, 2, and 5 in that essay) enough to justify implementing a rules engine? Or am I barking up the wrong tree entirely? I've never worked with a rules engine before, so I'm not quite sure what I'd be getting myself into...

LF

I would think that the if/else method might be a little difficult, and a whole lot of writting, and very slow O(n) processing.

My architecture would be very object orriented (it is java) where you would have each command being its own class. Then I would fill a either a binary tree or a heap. You would then lexiconical (don't think that is spelled nearly correct), so I will say an alphabetical search, (this is my edit) which would make your search be in O(nlog(n)) time. If you are not into Big-O notation, this is pretty darn fast. This is what you aim for on all searches, well... maybe you want O(1) but, take what you can.

You would need something like a toString() method for all of the options, and this would be used for a comparison. Also it would be important to have each of your commands extend a common "Command" class. Then if you are using an API previous to 1.5 you would code your tree to store Command objects which can then be narrowed as needed. If you have a large block of code when you are doing Object Orriented coding you most likely have not used a good method of programming. It sometimes saves a lot of brain power to write more code, I tend to do that often.

When you then get down to your main class it would run something like this:

public static void main(String[] args){

  //process your args

  BTree bt = new BTree();

  

  //If you are slicker than I am you might dynamically load these from

  //a directory of class files, which would cause commands to be treated like

  //plugins for easy use.

  bt.loadPlugins("plugin/directory");



  //or if you are not into dynamic class loading.

  bt.add(new Command1());

  bt.add(new Command2());

  bt.add(new Command3());

  //keep adding necessary command...



  YourStandardInputReader in = new YourStandardInputReader();

  String input, command, arguements;



  while(true){

     input = in.readLine();

     command = ParseInput.getCommand(input;);

     arguements = ParseInput.getArgs(input);



     bt.getCommand(command).executeCommand(arguements);

  }

   

}

In the above example the bt.getCommand(InputStream) hids a whole lot. Behind there you will need to effectively search your BTree/Heap based on the parsed command, you will have to make sure that you have an executeCommand(args) in your Command class so that it can be easily called (an thank Java for not handling inheritance like C) from the extended classes. Looking into this the core functionality might be implimented in as little a 200 lines, you can grab sorted BTree and heap code almost anywhere. The hard part would just be making the command plugins. Which would be a little code intensive because they are where the real work goes on.

This project would in my estimation be a fun little thing to do, and it would be very easy to maintain. If you get the core functionality correctly you can turn this into a base program to expand towards any CLI functionality you want.

Dan @ Code Town

(Edited by WarMage on 09-28-2004 05:53)

quote:

---

It sometimes saves a lot of brain power to write more code,

---

which is why I ended up with what I did, although in the long run, hundreds of if-else-if's makes your brain hurt after staring at it long enough.

What you explained is real close to what I was trying to piece together in my head yesterday. I still have all the code/snippets I wrote in Data Structures and Prog. Algorithms (I hope), so finding a binary tree or heap in there shouldn't be too hard. It's just making all the puzzle pieces fit together that's a challenge, because, of course, they don't bother talking about that in any of our classes. The prof will cover all sorts of specific examples and have you calculate runtimes of every search and sort algorithm he knows of, but you never apply it to a larger program so you never see the big picture. ... Enough of a rant for now...

Thanks WarMage, that helps a lot. Now that I have a general idea of where it's headed, I can start filling in pieces when I get time.

quote:

---

Then if you are using an API previous to 1.5 you would code your tree to store Command objects which can then be narrowed as needed.

---

What if I were using 1.5? I'm using 1.4.2, so it's not an issue, but what changed in 1.5? I've heard various people mention that there were some big changes, but I haven't taken the time to check it out any more than that.

WarMage: What you have described is a Recursive Descent parser. I was just going to recommend that a Recursive Descent parser might work better than if-else if, although I like if-else if for small languages (50 key words of less).

I would only use Recursive Descent over if-else if when the language is large enough to warrent it. Recursive Descent is easier to write than a rules engine, but can quickly get out of hand so you don't want to use it for really big languages.

When you say rules engine, is that the same as a state machine? I seem to think they are slightly different, but I've heard people use the terms interchangably.

It sounds as if you have not written the syntax diagrams for your language. If you haven't, that is the first thing you should do. The syntax diagrams will help you to see the language as a whole and also will help you to recognize where the various "parts of speech" (so to speak) fit into the language. This can help you to reduce the size of your parser as well as the syntax analyser.

-- not necessarily stoned... just beautiful.

So far, I'm up to about 40 keywords I think. It started out much smaller (about 10-15 keywords), but it grew shortly after I got it working ::

I'm not sure about the differences between a rules engine and a state machine either. I haven't used either very much (a rules engine not at all), but looking back at what I did, it's some combination of a state machine and if-else-if. I'm having to relearn what I did since I haven't looked at any of this code in about 2 months, and I must have been really tired when writing parts because there are one or two spots that I've noticed that I can't figure out why I did what I did...

Syntax diagrams - I wrote them out early on, but once I added to it I just started putting things in where they fit (I know I know, bad practice). I'll have to go through and re-write my diagrams for everything I have now and see where I end up.

The change in 1.5 that I am talking about is that sun has again done the smart thing and taken a bit of C.

If you often use java Vectors or Lists you will realize that it can be a pain to write

MyObject o = (MyObject)vector.get(i);

In 1.5 the whole narrowing conversion isn't needed because you can write syntax like:

Vector<MyObject> o = new Vector();
MyObject o = vector.get(i);

This is their new implimentation of generics. It is some really good stuff. I haven't jumped onto the 1.5 train yet because, I just don't trust it yet. I want to wait and see if it takes off, and if some of the newer features are fully adopted. They have some enumeration additions that are very interesting.

foreach o in c { }
for (Object o : c) { }

then you have "eachof"

Some of this stuff is really frightens me for some reason. I keep thinking it should make me really happy, but I just am not.

Dan @ Code Town