what sort of pattern should I be looking at here.

I am writing a system to manage batch-jobs and the hosts that run them.
Currently there are about 4 different types of jobs will be managed. It is
rare that new job types are introducted to the system.

The jobs use text files for settting the runtime parameters. There are 2
settings I am interested in, in these parameter files. But each job type
has a different format of parameter file. So while I am always interested
in the same two params, how I parse the parameters file depends on the job
type. These parameter files often (not always) determine the Host that the
job will run on.

The other unique aspect of the varying job types is the command used to run
the job.

All other apects of a job are the same.

In my first system design, I created on Job object, and used a constant, to
set the job type. I then implemented the getCommand() call, using switch
based on the job type, to return the appropriate string.

A method in the managing class did the parsing of the parameters files, and
set the appropriate methods in the Job objects, i.e., setRuntime(),
setMemUsage(), etc.

I am not nutz about this design.

I thought about creating an abstract Job, then inheriting from it for each
of then job types, implementing appropriate getCommand() and
getParametersFromFile().

My other idea was to use an abstract factory.

Any thoughts?

~S

Shea Martin wrote:
> I am writing a system to manage batch-jobs and the hosts that run
them.
> Currently there are about 4 different types of jobs will be managed.
It is
> rare that new job types are introducted to the system.
>
> The jobs use text files for settting the runtime parameters. There
are 2
> settings I am interested in, in these parameter files.


>But each job type has a different format of parameter file.

What does that mean, differnt format for parameter file.

> So while I am always interested
> in the same two params, how I parse the parameters file depends on
the job
> type. These parameter files often (not always) determine the Host
that the
> job will run on.
>
> The other unique aspect of the varying job types is the command used
to run
> the job.
>
> All other apects of a job are the same.
>
> In my first system design, I created on Job object, and used a
constant, to
> set the job type. I then implemented the getCommand() call, using
switch
> based on the job type, to return the appropriate string.

what string are you talking about.

>
> A method in the managing class did the parsing of the parameters
files, and
> set the appropriate methods in the Job objects, i.e., setRuntime(),
> setMemUsage(), etc.
>
> I am not nutz about this design.
>
> I thought about creating an abstract Job, then inheriting from it for
each
> of then job types, implementing appropriate getCommand() and
> getParametersFromFile().
>
> My other idea was to use an abstract factory.
>
> Any thoughts?
>
> ~S

What i can understand is that the job is selected depending on the two
parameter files and then job object selects the Host on which it should
be executed. I think you should use the Command Pattern.

Saurabh Aggrawal