[Tutor] design of Point class

Alan Gauld alan.gauld at btinternet.com
Tue Aug 24 01:45:36 CEST 2010

"Gregory, Matthew" <matt.gregory at oregonstate.edu> wrote

>> class Vehicle:
>>     def start(self, key):
>>     def go(self, key):
>> class Truck(Vehicle):
>>     # add other truck-like methods
>> class KeylessTruck(Truck):
>>     # Some military vehicles are designed to not require keys.

Aside: Most modern high-end cars are keyless too! ;-)

>>     def go(self):
>>     def start(self):
>> Can you see the problem? If the caller is expecting a Truck, and 
>> pass a
>> key to the truck.go() method, they will get an exception if you 
>> give
>> them a KeylessTruck instead of a Truck. This is a Bad Thing.

> Yes, this absolutely makes sense, but I'm less clear on how to solve 
> it.

There are several ways. Where you cannot change the original
interface - which wrongly assumed that all vehicles need keys - you
can introduce a default key parameter in which the method just ignores
the key and provides a default value(None?) if not provided.

Its messy and I'd definitely comment it to make it clear the key is
only to preserve the inherited interface but its probably the simplest 

> What I would think is that Vehicle shouldn't be defining start

Defining start is probably OK (I can't think of a vehicle that doesn't
start in some way or other), but requiring a key is a mistake since
many vehicles don't use keys (think rickshaw or trolley bus etc)

> and this should be left up to a delegate within the subclasses?

I'm not sure a delegate would help here, especially if you want
to start a list of vehicles.

> Or am I showing my ignorance?

No, just uncovering the challenges of OO design. There is no
perfect solution, all models are approximations. Experience tends
to build better approximations but never perfect ones.

And sometimes breaking the LSP and working round the consequences
(try/except...) is the best - ie most pragmatic - solution. But that
should be the least favourite choice, try to maintain interfaces if 


Alan Gauld
Author of the Learn to Program web site

More information about the Tutor mailing list