[Tutor] do_it()

[Alan Gauld]

> obj = myObject(param, param, param)
> obj.do_it()  #or obj.action() etc
>
> Are there any commanding advantages to making this sort of
functionality
> into an object?

No, but there some minor advantages.

> The above example is easier written and used as:
>
> myfunc(param, param, param)

Only easier used if you never change the program.
Making do_it a method allows you to subclass the entire
program and change the way it starts by overriding the
do_it() method.

You can then have another object use your program as
a sub-application by calling the do_it method. So far
the function approach works fine too, but...

You can in fact can have a list of such applets and
call each in turn, or in random order or from a menu
system etc, by using a single bit of common code:

for applet in app_list:
   applet.do_it(p,p1,p2)

And in fact your applet launcher doesn't need to be
changed when you create another variation of your applet
either...

Its not compelling, but can be handy.

The real reason for doing it is that its just folowing
the OO paradigm to its logical conclusion. Everything
in the application is an object, including the application
itself...

> I ask because I have just written a MAKE utility, and having
started off as
> an object I really don't know what the advantages are above a
simple
> function.

If its a single object with a single function, probably none.
I would expect a Make program to have classes representing files,
commands, rules, dependencies etc...

The Make application object then binds those together with
attributes containing lists of rules, and files and the
rules in turn containing commands, file-patterns etc.

But maybe thats what you have?

Alan G