On Wed, 08 Aug 2012 09:27:40 -0700, rusi wrote: > I once sat for a presentation of a wannabe university teacher. The > subject she chose was object-orientation. > > She spent some time on the usual dope about employee, manager etc. > Finally she reached the base-class: Person. > > Or so we thought... > > Then suddenly she started 'extending' the bases: Person inherits from > mammal inherits from vertebrate inherits from animal > > Now in principle one could perhaps find an app where this whole > inheritance hierarchy makes sense.
Presumably female managers who breast-feed their children inherit that method from Mammal. And if you were modelling a futuristic space station with both human and non-human beings (perhaps for a game?), then distinguishing between those that inherit a breathe_oxygen() method from Animal versus those that inherit absorb_magnetic_energy() from Acturian_Magnevore might be useful. I wasn't at this talk, but I would be willing to bet that she wasn't suggesting that any specific application needs to encompass the entire inheritance hierarchy from Animal to Junior Manager Of Pencil Sharpeners, only that the Inheritance design pattern was capable of doing so. > But I cannot think of one. (Maybe something from Orwell??) > > In any case this is the incident that makes me side with your "NO > PERSON" dictum. The problem with this dictum is that while it recognises that (e.g.) a Customer is not necessarily a person (it can be another business unit or a company), that's more the exception than the rule. A Student is always a person. So is an Employee or Employer, a Surgeon or Patient, or the subject of birth, death and marriage records. (As they say: I'll believe that corporations are people when Texas executes one.) You can, of course, ban the name "Person" from your classes and databases. But that's a mere cosmetic quirk -- you're still modelling people as objects and/or database records, whether you use the word or not. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
