Инициализация и протоколы

Метод __init__

Теперь, когда вы знакомы со связанными методами, настало время рассказать про самый важный метод в Python: метод __init__ ("dunder-init", "дандер инит"). Этот метод отвечает за инициализацию экземпляров класса после их создания.

На прошлых уроках Бобу — экземпляру класса Person, я задавал имя уже после того, как сам объект был создан. Такое заполнение атрибутов объекта и выглядит громоздко и может приводить к разного рода ошибкам: объект может какое-то время находиться в "недозаполненном" (более общее название — "неконсистентном") состоянии. Инициализатор же позволяет получить уже полностью настроенный экземпляр.

Реализуем класс Person так, чтобы имя можно было указывать при создании объекта:

>>> class Person:
...     def __init__(self, name):
...         self.name = name
...
>>> bob = Person('Bob')
>>> bob.name
'Bob'
>>> alice = Person('Alice')
>>> alice.name
'Alice'

Теперь нет нужды иметь в классе атрибут name = 'Noname', ведь все объекты получают имена при инстанциировании!

__init__ — не конструктор!

Иногда даже в источниках уважаемых авторов можно встретить упоминание dunder-init, как "конструктора". Предостерегаю вас: не делайте так! Конструкторы в языках программирования, поддерживающих ООП, именно создают экземпляры: выделают память под объект, возвращают ссылку на этот объект. То есть до вызова конструктора экземпляр не существует. dunder-init же получает ссылку на уже существующий объект в аргументе self. Как говорится, "инициализатор" и "конструктор" — это две большие разницы!

Рассмотрим такой код:

>>> bob = Person('Bob')
>>> Person.__init__(bob, 'Alice')
>>> bob.name
'Alice'

Видите, dunder-init всего лишь изменяет существующий объект. А был бы он конструктором, мы бы получили новый экземпляр класса Person. Мы же всего лишь переименовали Боба в Элис (то-то он удивится!).

Методы и протоколы

Вы заметили, что Python сам вызывает метод __init__ в нужный момент? Это же касается большинства dunder-методов: таковые вы только объявляете, но вручную не вызываете. Такое поведение часто называют протоколом (или поведением): класс реализует некий протокол, предоставляя нужные dunder-методы. А Python, в свою очередь, работает с объектом посредством протокола.

Продемонстрирую протокол получения длины объекта:

>>> class Person:
...     def __init__(self, name):
...         self.name = name
...     def __len__(self):
...         return len(self.name)
...
>>> tom = Person('Thomas')
>>> len(tom)
6

Я объявил метод dunder-len, и объекты класса Person научились возвращать "свою длину" (да, пример надуманный, но суть отражает). Вызов функции len на самом деле приводит к вызову метода __len__ у переданного в аргументе объекта!

Протоколы и "утиная типизация"

Существует такой термин: "утиная типизация" ("duck typing") — "Если что-то крякает как утка и плавает как утка, то возможно это утка и есть!". Данный термин, пусть и звучит как шутка, описывает важный принцип построения абстракций: коду практически всегда достаточно знать о значении, с которым этот код работает, что это значение обладает нужными свойствами. Всё остальное — не существенно.

Если коду достаточно знать, что сущность умеет плавать и крякать, то код не должен проверять сущность на фактическую принадлежность к уткам. Это позволит коду работать с робо-утками, даже если все настоящие утки вымрут, ведь код работает с абстрактными утками!

Протоколы в Python являются представлением идеи утиной типизации в коде. Так циклу for незачем знать, что за источник он обходит, лишь бы источник поддерживал протокол итерации. Так и вы, когда возникает желание узнать о значении, уж не список ли это, всегда проверяйте себя: возможно вашему коду не нужно знать, что значение является списком!

Протоколов в Python существует великое множество. Вы можете заставить объекты вашего класса вести себя подобно словарям и спискам (bob['key'] и bob[-1]), походить на функции (bob(42, foo=True)), уметь "складываться и умножаться" (bob + alice). И Python будет обращаться с объектами соответствующим образом, ведь он тоже всегда следует протоколам — не смотря на то, что уж интерпретатору-то всегда известно, что за объект вы ему подсунули!