something else to keep in mind, is the distinction between "IS-A" and "is-instance-of"

When designing a class hierarchy, the concepts of IS-A and HAS-A get thrown arround alot, but you have to always keep in mind that you are talking about "classes of things" -- not hte things themselves.

All i know about your data and your application is what you've posted in this thread, so maybe there's more going on then i understand, but it seems to me that "AcmeLtd" is an instance-of "Company", and "AcmeLtd IT" is an instance-of "Company::Division". Unless of course, you have some reason to instantiate many different instances of AcmeLtd ?

The nature of your data confuses me, so instead let's Imaging you are dealing with Animals. you've got the class "Animal" and hte subclasses Dog and Cat (a Dog IS-A Animal). now based on the nature of your data, do you want lots of instances of "Dog" representig a breed as an attribute, or do you want a seperate subclass for each breed, with each instance representing a physical dog with a name?

This...

# Dog ISA Animal

my $german_sheperd = new Dog(BIG, FURRY);
my $collie = new Dog(MEDIUM, SHORT_HAIRED);
my $poodle = new Dog(SMALL, GOOFY);
[download]

# Dog ISA Animal
# Dog::Poodle ISA Dog
# Dog::Collie ISA Dog

my $fluffy = new Dog::Poodle('fluffy');
my $spot = new Dog::Poodle('spot');
my $fido = new Dog::Collie('fido');
my $stray = new Dog();
[download]

The latter, a seperate subclass for each breed. I'll try and explain why, and maybe it'll help make things a bit clearer (fingers crossed).

The Company and Company::Division classes are a kind of framework, which AcmeLtd and AcmeLtd::IT build upon to provide specific functionality, overriding methods to do so.

..........
..........

you know, at this point lots of stuff has just clicked into place in my head, and i've realised that by changing some other stuff around, I can get rid of the requirement to start with the Company object, and just start directly with AcmeLtd (which will of course inherit generic processing functionality from Company).

I think the problems i've had in trying to figure out how to structure this have come about because i don't have the AcmeLtd class in the system right now, and all the information that is going to go into that is pulled out of config files. When i decided to add the class in, i didn't analyse the change fully, and have been trying to do things the hard way as a result.

Thanks enormously for the above reply; in trying to answer it's made me think more about the situation, and helped me understand things better myself.

hossman++ # would have voted the above reply up if i could have

 /-----------\             /-------------------\
 |  Company  |--@(has-N)-> | Company::Division |
 \-----------/             \-------------------/
      /|\                          /|\
       |                            | (is-a)
       |                            |
       |                   /- - - - - - - - - -\
       | (is-a)             AcmeLtd::Division ?
       |                   \- - - - - - - - - -/
       |                           /|\
       |                            | (is-a)
       |                            |
 /-----------\               /-------------\
 |  AcmeLtd  |-----create--> | AcmeLtd::IT |
 \-----------/               \-------------/
[download]

A company may have more than one division, and the number may change over time, but the distinction between them doesn't really matter. So consider a collection of generic divisions.

In the AcmeLtd construction, or later in its operation, you may choose to add an AcmeLtd::IT instance to the collection of generic divisions of the company. You may choose to nix it later, or outsource it to some Vendor::IT that has a similar interface.

If there's nothing particularly distinguishing about all AcmeLtd::Divisions that would not be required of any generic Company::Division, then kill that class.

(ASCII is not a very good way to draw Booch diagrams.)