Gee, this sounds just like nearly every book I've read about OO design. It also is not at all how I've seen OO design done well.

Books that teach OO design have to cover some basic topics. One of the big ones is inheritance. This means that authors of OO books end up asking themselves the question "What should we design that will teach about inheritance". And when many read their books, they come away thinking that the first step when designing objects is "How should I use inheritance in this design?".

Both my experience with OO design and some of the better books on OO design that I've read indicate that you shouldn't be thinking much about inheritance at all when you start a project, except perhaps to think "I won't use inheritance unless the need for it becomes clear and obvious".

The best and most common use of inheritance is a simple inheritance of interface. This is like prototyping a subroutine except that you end up prototyping a whole class of subroutines (methods). But Perl doesn't support prototyping of subroutines (Perl has subroutine prototypes but they aren't well suited for using to prototype subroutines, despite the name) and Perl's OO doesn't support inheritance of interface. There are some modules you can use that tack on one sort or another of inheritance of interface, but this isn't built into Perl.

Another type of inheritance is inheritance of member variables. Perl doesn't really support that either.

The only type of inheritance that Perl supports in inheritance of implementation. And, although some OO books will claim that inheritance of implementation is one of the major advantages of OO because it promotes code reuse, the people I know who have done a lot of real work with OO (mostly in C++, just in case you think I'm talking about Scheme or some real OO language, which I'm not), think that inheritance of implementation is one of the worst ways you can do code reuse.

Inheritance (as you've surely read) defines an "is a" relationship. And if A "is a" B, then they are very, very tightly bound together. It is much better to reuse your code via a looser bond. Perl supports a ton of these. For OO code, the common tool is "aggregation" (also called "composition" and several other names) which represents a "has a" relationship.

Other methods of code reuse that fit well with Perl and can be used with OO (but that aren't OO techniques) include importing/exporting functions and tons of (other) tricks with code references and closures.

Also, OO books tend to create objects like PERSON and DOG. You aren't going to make an object that captures enough functionality that is deserves to be called "PERSON". People have favorite colors, food alergies, height/weight, etc. Although you might decide that CUSTOMER is a PERSON and that EMPLOYEE is a PERSON, you are going to track very different information about EMPLOYEE vs. CUSTOMER. Now, there may be some information that you track about both, but that information isn't well described by "PERSON". I'd be more likely to have a CONTACT object which has things that I need to know about a person that I'm going to contact (name, title, address, phone).

So I certainly wouldn't have VENDOR is a PERSON. I'd have a VENDOR has some CONTACTs.

Now, even that may not be worth the effort. Perhaps you should just have a VENDOR and a CUSTOMER and not try to abstract out shared things. I mean, if the only code that you are going to end up sharing is a few 2-line accessor methods like getAddress() and setAddress(), then I don't think the complexity of trying to share bits of the design will be a net win.

        - tye (but my friends call me "Tye")