Example 1-17. PP4E\Preview\person_alternative.py
"""
Alternative implementation of person classes, with data, behavior,
and operator overloading (not used for objects stored persistently)
"""
class Person:
"""
a general person: data+logic
"""
def init(self, name, age, pay=0, job=None):
self.name = name
self.age = age
self.pay = pay
self.job = job
def lastName(self):
return self.name.split()[-1]
def giveRaise(self, percent):
self.pay *= (1.0 + percent)
def str(self):
return ('<%s => %s: %s, %s>' %
(self.class.name, self.name, self.job, self.pay))
class Manager(Person):
"""
a person with custom raise
inherits general lastname, str
"""
def init(self, name, age, pay):
Person.init(self, name, age, pay, 'manager')
def giveRaise(self, percent, bonus=0.1):
Person.giveRaise(self, percent + bonus)
if name == 'main':
bob = Person('Bob Smith', 44)
sue = Person('Sue Jones', 47, 40000, 'hardware')
tom = Manager(name='Tom Doe', age=50, pay=50000)
print(sue, sue.pay, sue.lastName())
for obj in (bob, sue, tom):
obj.giveRaise(.10) # run this obj's giveRaise
print(obj) # run common str method
Notice the polymorphism in this module’s self-test loop: all three objects share the
constructor, last-name, and printing methods, but the raise method called is dependent
upon the class from which an instance is created. When run, Example 1-17 prints the
following to standard output—the manager’s job is filled in at construction, we get the
new custom display format for our objects, and the new version of the manager’s raise
method works as before:
<Person => Sue Jones: hardware, 40000> 40000 Jones
<Person => Bob Smith: None, 0.0>
<Person => Sue Jones: hardware, 44000.0>
<Manager => Tom Doe: manager, 60000.0>Step 3: Stepping Up to OOP | 33