[Tutor] Classes in separate files

[Alan Gauld]

"James" <jtp at nc.rr.com> wrote

> The issue is, however, that I'm not sure the "best" way to pass 
> things
> into classes, and the "best" way to get something back.

In an OOP syustem you don;t normally have to pass a lot into
a method since most of the data should be internal to the object
Often a single object parameter is all thats required - if any.

> I have a main file, main.py. It's going to create several instances
> that are defined by a class in class1.py. *However*, I also need to
> instantiate numerous other classes defined in class2.py.

The files issue is largely irrelevant and no different for OOP
than for procedural coding. Keep related classes in a single
module. Put unrelated classes in another module to ease
reuse.

> class1.py has a few classes, such as
> - ticket (represents a ticket opened to fix bugs in a program)
> - ticketAnalyzer (an object who looks at all the tickets 
> opened/available)

Its convention to make class names start with an upperc ase letter.
Attributes/methods/instances start with lowercase.

As to TicketAnalyzer - why doesn't the ticket analyze itself?

> class2.py has a few classes, as well, such as:
> - codemonkey (defines a person that is going to take tickets and fix 
> them)

So has a method called fix(aTicket)?

> - codereviewer (defines a person who will double check a 
> codemonkey's work)

So has a method called check(aTicket)?

These two classes sound like subclasses of a common
superclass - called Person maybe?

> main.py has the "main" function, and will be what is actually 
> invoked at
> the command line. In main.py I can instantiate an object of type
> ticket, an object of type ticketAnalyzer, and then instantiate
> code{monkey,reviewer} classes. However, how do I get codemonkey and
> codereviewer to call methods on the ticket and ticketAnalyzer 
> classes?

in the CodeMonkey.fix(aTicket) method the code can reference aTicket.

as in:

def fix(self, aTicket):
     faultType = aTicket.analyze()
     #   do whatever you do to fix it?!
     aTicket.status = aTicket.analyze()  # check if its fixed
     return aTicket.status

> The only solution I can think of here is having the main function 
> (in
> main.py) which instantiates all these objects actually *pass in* to
> the codemonkey and reviewer the reference to the specific objects
> ticketAnalyzer and ticket. Is this the best way to do it?

Its one approach. Without knowing a lot more about the problem
it seems a reasonable way forward

> handle that behavior in the __init__ of code{monkey,reviewer}?

Almost certainly not. the monkey and reviewer will presumably
work on more than one ticket so you want to feed the work in
progressively rather than create new instances for each ticket
- I assume, maybe not!

You don't say much about what the system does, which is
pretty fundamental to OOD since it is driven by the behaviour
required. I'm guessing that you want to be able to create
multiple tickets and assign them to a group of monkeys
and reviewers? The system then manages the progress
of the tickets?

> I instead create a method inside of the codemonkey and reviewer
> classes that accepts the object pointer to the ticket objects and 
> then
> interact between ticket/code* objects as such?

That's the way I'd go.
OOP programs are all about objects interacting.
Think of the main function as being the global controller
kicking off the initial scenarios which then run as
semi-autonomous threads.

> I image it would be much easier to have everything in one file, but
> that goes against my grain. ;)

As I said earlier the physical location of the code makes
no difference to the logical design of the system. A few
import startements will deal with that.

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld