views:

29

answers:

1

I'm attempting to automate a really old dos application. I've decided the best way to do this is via input redirection. The legacy app (menu driven) has many tasks within tasks with branching logic. In order to easily understand and reuse the input for these tasks, I'd like to break them into bit size pieces. Since I'll need to start a fresh app on each run, repeating a context to consume a bit might be messy.

I'd like to create an object model that:

  • allows me to concentrate on the task at hand
  • allows me to reuse common tasks from different start points
  • prevents me from calling a task from the wrong start point

To be more explicit, given I have the following task hierarchy:

START
A
  A1
    A1a
    A1b
  A2
    A2a
B
  B1
    B1a

I'd like an object model that lets me generate an input file for task "A1b" buy using building blocks like:

START -> do_A, do_A1, do_A1b

but prevents me from:

START -> do_A1 // because I'm assuming a different call chain from above

This will help me write "do_A1b" because I can always assume the same starting context and will simplify writing "do_A1a" because it has THE SAME starting context. What patterns will help me out here? I'm using ruby at the moment so if dynamic language features can help, I'm game.

A: 

EDIT: after re-reading your question, I realized I misunderstood it. Let me answer what you actually asked...

I would create a hierarchy of classes. The simplest ones would be have functions like "do task A1b" that would output the appropriate steps to accomplish this. On top of that, I would build functions that would call the sub-tasks in specific orders to accomplish specific goals.

Pretending VIM was the program being controlled, the first level tasks would be things like 'Enter insert mode' 'Enter command mode' 'write the file' or 'input this arbitrary set of inputs'. On top of this I would build functions like 'insert "foobar" into the open file at the start of line 5' which would call the lower-level tasks.

David Oneill