[Tutor] design questions: pythonic approach to ostriches

Smith, Jeff jsmith at medplus.com
Mon Apr 25 15:33:00 CEST 2005

This is an excellent observation and points to the real problem with the
original question.  The problem is that the base class has more features
than some of the classes that will be dervied from it which is usually
just plain wrong.

Think about it in the abstract.  The Bird class makes the statement: all
birds fly.  Then you want to turn around and define a Bird that doesn't.
Even doing

def fly:

makes no sense since what you've really done is to re-defined what 'fly'
means for this bird.  Again in the abstract:  all birds fly and for some
birds that will mean that they don't.

The only sensible solution to this that will cause the least confusion
from a maintenance stanpoint and allow for the largest possible reuse is
multiple inheritance for languages that support it.  


-----Original Message-----
From: tutor-bounces at python.org [mailto:tutor-bounces at python.org] On
Behalf Of Alan Gauld
Sent: Sunday, April 24, 2005 3:48 AM
To: Brian van den Broek; Tutor
Subject: Re: [Tutor] design questions: pythonic approach to ostriches

> I do remain a bit surprised that there seems to be no way to
> what I naively thought would be the obvious solution -- to remove an 
> inherited method from the instance's dictionary.

You can, as Kent said, override the method to do nothing. Some
languages, like Eifell offer better support for that than others.

But there is a danger in removing methods too. By doing so you break one
of the fundamental principles of inheritence: that everywhere that you
use the superclass you can use the sub class.

If you remove the fly() method from your subclass of birds code like
this will break:

birds = [ aSwallow, anOstrich, anEmu, anEagle]

for bird in birds:

Whereas if you simply make fly a null method you can still call it but
nothing happens - a lot safer...

But conceptually the problem (and it is common) is that bird has a
fly() method when not all birds can fly - the object model is broken at
a high level of abstraction.


Alan G.

Tutor maillist  -  Tutor at python.org

More information about the Tutor mailing list