Python Design Patterns - composition vs. inheritance

[Diez B. Roggisch]

> As a very simplified example, if I had two classes, Pet and Owner, it
> seems that I would not have Pet inherit from Owner, since a pet 'has
> an' owner, but not 'is an' owner. If this is correct, does my code
> below reflect this? I passed the owner object into the pet object's
> constructor - is this the right way to do it?

Yes. Of course there are other ways, establishing the connection later, 
and of course making the Owner know her pets. But your unidirectional, 
ctor-passed implementation is sensible.

> Also, I've seen talk that ideally you shouldn't have too many "dots"
> in your method calls, instead using delegates to the methods and
> attributes. Can anyone elaborate on this? Ideally, should I be writing
> getattr() methods so I can do pet.address instead of
> pet.owner.address? Should I be doing the same with owner's methods
> like I did with get_foo()?

No, that's certainly not a good idea. And I'm under the impression you 
misunderstood something there in the original lecture/explanation.

The reason is simple: by adding these methods, you essentially extend 
Pet's knowledge as a class to what only its owner has to know. Which 
makes no sense. Why should pets know about addresses? Or cars? Or 
anything else that belongs to the owner only.

Of course there are just reasons to create such delegation methods - if 
for example the property/method is of general interest to the Pet, but 
implemented by means of the owner. But I've got difficulties even to 
imagine such thing, at least in your actual example.

Diez