One school of thought is that anything that is identifiable outside the context of another object is itself an object. A customer order in one sense is nothing but an old shopping cart. It reflects the contents of a shopping cart from a previous visit, and it probably extends the amount of information normally associated with a shopping cart.

So, as you can see, an order is a shopping cart with some extra info. Common to the school of thought that I am describing (in a limited sense, since OO is not an entirely easy concept to describe within the constraints of this node) is the use of is a and has a descriptions in as many places as possible. By designing this information, a clearer picture as to what objects are "super-objects" and what objects are "detail-objects" will emerge. The "super-objects" will contain the necessary code to meet basic needs and the "detail-objects" will contain the majority of the code in relation to that object. You'll probably override/overload some of the functionality in the "super-objects" when you get to the "detail-objects".

I had a pretty decent book in my OO class at school written by Timothy Budd called An Introduction to Object-Oriented Programming, which covers a good portion of theory. I thought it was useful, albeit the book lacks Perl implementation.

ALL HAIL BRAK!!!