[Tutor] How to design the structure of multi-steps(and substeps)scripts

[Alan Gauld]

"leechau" <charlze at sohu.com> wrote


> def step1:
>    local_var1 = ...
>    # some other variable definitions for step1
>    def substep11:
>        pass
>    # more substeps
> ...
> global_var1 = ...
> # more global var definitions...
> if step1.return_success:
>    step2

Since this is obviously pseudo code I'll assume the
real code has fixed the synrax issues.

> steps in one module, where one step corresponding to one funciton 
> and
> one substep corresponding to one nested function.

While that may seem logical it does limit reuse of the subfunctions.
Do these subfunctions look very similar? Could the be written more
generically - perhaps using some parameters to deal with
differences? If so take them outside the steps.

Then define your steps as tables of functions

step1 = [substep1,substep2,substep3]

and call using a loop:

for step in step1: step()

> maintain this script because of totally 1000+ lines of code.

Thats getting close to the biggest I like my modules to be but
not huge. The size is not the problem - after all thats what
search is for in the editor! :-)

> when I manipulate different projects with this script I need to 
> modify
> the value of some variables and detailed task logic. Obviously it's 
> a
> dirty work to modify the source code directly for different 
> projects.

If you are reusing then break the modules down to the size of
the unit of reuse. So if you only use a single step then make
each step a module. BUt if you reuse the entire group then
keep it as one.

> ....If I should put the default value of a
> variable and high level task logic in a abstract class, and define
> specific value and detailed task logic in concrete subclass?

That would be good to get rid of the globals at least and enable
different projects to modify the instance values for their own 
purposes.

> any design patterns available for this kind of multi-steps scripts?

I'd definitely consider a data driven approach as suggested above,
but a lot depends on how complex the real logic is inside the steps.
If it can be simplified to little more than a sequence of substeps
and those substeps can be generic then a table driven style will
greatly simplify the code. Another pattern that is likely to apply
is a state machine, either implemented using state classes or
as a table.

But without knowlege of the detail of the real code we cannot
make definite recommendations.

HTH,


-- 
Alan Gauld
Author of the Learn to Program web site
http://www.alan-g.me.uk/