>>> from person import Person >>> from manager import Manager
>>> bob = Person(name='Bob Smith', age=42, pay=10000)
>>> sue = Person(name='Sue Jones', age=45, pay=20000)
>>> tom = Manager(name='Tom Doe', age=55, pay=30000)
>>> db = [bob, sue, tom]
>>> for obj in db:
obj.giveRaise(.10) # метод по умолчанию или специализированный >>> for obj in db:
print(obj.lastName(), ‘=>', obj.pay)
Smith => 11000.0 Jones => 22000.0 Doe => 36000.0
Реструктуризация программного кода
Прежде чем двинуться дальше, рассмотрим еще несколько альтернативных вариантов реализации. Большинство из них подчеркивают преимущества модели ООП в Python и рассматриваются здесь для краткого знакомства.
Расширение методов
Во-первых, обратите внимание на некоторую избыточность в примере 1.16: расчет увеличения оклада производится в двух местах (в двух классах). Мы могли бы реализовать специализированный класс Manager, не замещая унаследованный метод giveRaise новой реализацией, а расширяя его:
class Manager(Person):
def giveRaise(self, percent, bonus=0.1):
Person.giveRaise(self, percent + bonus)
Вся хитрость заключается в непосредственном вызове версии метода суперкласса и явной передаче ему аргумента self. При таком подходе мы также переопределяем метод, но на этот раз мы просто вызываем универсальную версию после добавления 10-процентной надбавки (предусмотренной по умолчанию) к указанному значению в процентах. Этот прием позволяет уменьшить избыточность программного кода (оригинальная логика метода giveRaise находится в одном только месте, что упрощает возможность ее изменения в будущем), и его особенно удобно использовать при переопределении методов-конструкторов суперклассов.
Если вы уже знакомы с особенностями ООП в Python, то должны знать, что этот прием работает благодаря возможности вызова методов как относительно экземпляра, так и относительно имени класса. Вообще говоря, следующие два вызова являются эквивалентными, и можно использовать обе формы:
instance.method(arg1, arg2) class.method(instance, arg1, arg2)
В действительности, первая форма отображается во вторую - при вызове метода относительно экземпляра интерпретатор Python отыскивает в дереве наследования ближайший класс, в котором имеется требуемый метод, и вызывает его, автоматически передавая экземпляр в первом аргументе. В любом случае, внутри метода giveRaise аргумент self будет ссылаться на экземпляр, являющийся объектом вызова.
Формат отображения
Чтобы получить дополнительное удовольствие от использования ООП, мы могли бы добавить в наши классы несколько методов перегрузки операторов. Например, метод__str__, реализованный здесь, возвраща
ет отформатированную строку для отображения наших объектов при печати объектов целиком - такое представление выглядит гораздо лучше, чем предусмотренное по умолчанию:
class Person:
def __str__(self):
return ‘<%s => %s>’ % (self.__class__.__name__, self.name)
tom = Manager(‘Tom Jones’, 50)
print(tom) # выведет: <Manager => Tom Jones>
Здесь атрибут__class__содержит ссылку на ближайший класс, экземпляром которого является объект self, даже при том, что метод__str__
может оказаться унаследованной версией. Метод__str__позволяет вы
водить экземпляры непосредственно, вместо того чтобы выводить отдельные атрибуты. В метод__str__можно было бы добавить цикл, выполняющий обход словаря атрибутов__dict__экземпляра и отобража
ющий все атрибуты. Но это лишь краткий обзор, поэтому оставим это предложение для самостоятельного упражнения.
Мы могли бы даже реализовать метод__add__, чтобы оператор + авто
матически вызывал метод giveRaise. Нужно ли это - другой вопрос. Использование оператора + для увеличения оклада может быть истолковано неправильно теми, кто впоследствии будет читать наш программный код.
Специализация конструктора
Наконец, обратите внимание, что в примере 1.16 при создании экземпляра класса Manager мы не передаем конструктору аргумент job. При необходимости мы могли бы передавать это значение в виде именованного аргумента, как показано ниже:
tom = Manager(name=’Tom Doe’, age=50, pay=50000, job=’manager’)
Причина, по которой мы в примере не включили передачу аргумента job, заключается в том, что в этом нет необходимости: если создается новый экземпляр класса Manager, занимаемая должность уже подразумевается классом. Тем не менее, чтобы не оставлять поле job пустым, возможно, имеет смысл явно реализовать конструктор для класса Manager, который будет заполнять это поле автоматически:
class Manager(Person):