Re: Re: OO: sharing data across inheritance

[skillet-thief]

Can you describe the problem that you're trying to solve with Parent and Child? There may be another way of attacking the problem.

I am starting to think that "another way" might be in order here. Here is basically what I am trying to do:

I am writing an LWP interface to an automated web publishing system. My interface already works, but is written as subroutines to which you have to pass lots of variables each time. Since my scripts are intended to be used by others, I wanted to clean them up and avoid passing around the same variables all the time. That is why I decided to do an OO rewrite.

More specifically: There is a certain amount of information that goes with the website to which the user publishes: passwords, directories, etc. Inside that site, there is a series of "journal issues" that have their own specific information, but they of course share the information pertaining to the site.

The relationship between Parent and Child in my original post was intended to describe these two different levels. I was thinking of the kind of relationship that exists, in DBI.pm, for example, between the database handle ($dbh) and the individual query objects ($sth).

So you are right about state. My Parent class is indeed intended to maintain state, while the Child class was supposed to actually do the real work. Does this mean that I should abandon an OO approach, or just quit trying inheritance?

Should my state data just be a class variable?

s-t

[adrianh]

I am writing an LWP interface to an automated web publishing system. My interface already works, but is written as subroutines to which you have to pass lots of variables each time. Since my scripts are intended to be used by others, I wanted to clean them up and avoid passing around the same variables all the time. That is why I decided to do an OO rewrite.

Lots of state information being passed around. Sounds exactly the sort of thing that belongs in one or more objects - so I think your instincts to move to an OO model are spot on.

More specifically: There is a certain amount of information that goes with the website to which the user publishes: passwords, directories, etc. Inside that site, there is a series of "journal issues" that have their own specific information, but they of course share the information pertaining to the site.

So a the Website has multiple JournalIssues - yes?

So you are right about state. My Parent class is indeed intended to maintain state, while the Child class was supposed to actually do the real work. Does this mean that I should abandon an OO approach, or just quit trying inheritance?

I think an OO approach is the right one, but I don't think that the relationship between Websites and JournalIssues is best modelled by inheritance.

Inheritance is used for modeling is-a relations. If it doesn't make sense to say that a JournalIssue is-a Website then inheritance is probably not the right solution to pick.

Just like the $dbh and $sth objects in DBI. A statement handle isn't a kind of database handle.

Instead you might want to look at having your Website maintain a list of JournalIssue objects internally.

Without knowing more about your application its a bit difficult to talk about specifics. I'd recommend trying to migrate to your OO model in a set of smaller steps.

If you see a bunch of state that your passing to every function wrap that up in an object and pass that instead. Do that a few times and you'll probably start seeing some of the subroutines as candidate methods for that object. Let the code guide you and you'll probably see some classes fall out fairly easily.