Инкапсуляция — одна из основ ООП. Мы договариваемся использовать только часть функциональности класса, а взамен получаем возможность работать с самыми разными типами, даже с теми, которые будут написаны после окончания работы над текущим кодом.
Компилируемые языки реализуют инкапсуляцию методом принуждения. Программист отмечает методы и поля как личные или защищенные, а компилятор играет в большого брата и проверяет что все используется в корректном контексте. На моей памяти война за способ использования private/protected минимум пару раз принимала нешуточный оборот.
Попадая в питон С++/Java-программисты начинают искать замену родным private/protected в этом мире безудержного эксгибиционизма. И, как правило, быстро находят два подчеркивания. Не совсем то, что хотелось бы, но довольно сильно похоже на private. В итоге нижнее подчеркивание быстро становится самым популярным символом в коде.
Я попробую показать, что:
- '__' — не эквивалент private и решает совсем другие задачи;
- Можно отлично жить без private/protected/friend. Оружие массового запрещения не единственный способ реализовать инкапсуляцию;
- При желании можно написать аналог private/protected и даже более гибкий контроль доступа для python (в следующем посте)
Итак зачем в python поля с двумя подчеркиваниями в начале имени. Пусть у нас есть такой код:
Без подсветки синтаксиса
from some_module import SomeClass
class SomeClassChildren(SomeClass):
def __init__(self):
super(SomeClassChildren, self).__init__()
self.some_field = 12
from some_module import SomeClass
class SomeClassChildren(SomeClass):
def __init__(self):
super(SomeClassChildren, self).__init__()
self.some_field = 12
Допустим код SomeClass очень большой или нам не доступен или постоянно неконтролируемо меняется или по любой другой причине мы не может быть уверенны, что какое бы благозвучное имя не было выбрано для some_field мы не можем быть уверенны, что не затрем поле с таким же именем в родительском классе. Компилируемый язык решил бы эту проблему, не позволив нам создать поле, если поле с таким именем уже унаследовано. Это не решает проблему полностью, но избавляет нас от странного поведения.
Для этого в питоне и есть поля с двумя подчеркиваниями в начале (но без двух подчеркиваний в конце). Когда компилятор питона видит подобное имя он дописывает к нему в начало еще одно подчеркивание и имя текущего компилируемого класса. Это можно увидеть с помощью питоновского дизассемблера:
Без подсветки синтаксиса
import dis
class A(object):
def func(self, x):
self.__attr1
class B(A):
def func(self, x):
self.__attr2
class C(A):
def func(self, x):
class C1(object):
def func(self):
x.__attr3
dis.dis(C1.func)
def r(self):
self.__attr4
class D(object):
func = r
dis.dis(A.func)
dis.dis(B.func)
C().func(A())
dis.dis(D.func)
dis.dis(lambda: A.__attr5)
import dis
class A(object):
def func(self, x):
self.__attr1
class B(A):
def func(self, x):
self.__attr2
class C(A):
def func(self, x):
class C1(object):
def func(self):
x.__attr3
dis.dis(C1.func)
def r(self):
self.__attr4
class D(object):
func = r
dis.dis(A.func)
dis.dis(B.func)
C().func(A())
dis.dis(D.func)
dis.dis(lambda: A.__attr5)
# dis.dis(A.func)
0 LOAD_FAST 0 (self) << object
3 LOAD_ATTR 0 (_A__attr1) << attribute name
# == self._A__attr1
# dis.dis(B.func)
0 LOAD_FAST 0 (self)
3 LOAD_ATTR 0 (_B__attr2)
# dis.dis(C1.func)
0 LOAD_DEREF 0 (x)
3 LOAD_ATTR 0 (_C1__attr3)
# dis.dis(D.func)
0 LOAD_FAST 0 (self)
3 LOAD_ATTR 0 (__attr4)
# dis.dis(lambda: A.__attr5)
0 LOAD_GLOBAL 0 (A)
3 LOAD_ATTR 1 (__attr5)
Итого '__' приводит к переименованию поля и позволяет использовать поля с одинаковыми именами в разных классах одной иерархии. Но это не мешает добраться до такого поля, например x._X__some_priv_field. BTW — если нужно сделать действительно скрытое поле, то можно и так:
Без подсветки синтаксиса
class MyProxy(object):
def __init__(self, proxifyed):
self.__dict__[self] = proxifyed # <<<
def __getattr__(self, name):
return getattr(self.__dict__[self], name)
class MyProxy(object):
def __init__(self, proxifyed):
self.__dict__[self] = proxifyed # <<<
def __getattr__(self, name):
return getattr(self.__dict__[self], name)
self.__dict__ — обычный словарь и ключами в нем могут быть не только строки. Злоупотреблять таким хаком не стоит поскольку много различных библиотек, например сериализаторы, сильно удивятся увидев в __dict__ нестроковой ключ.
Итак: '__' — это очень специфический аналог частного поля и он предназначен для несколько других целей.
Модификаторы доступа защищают программиста от случайного и преднамеренного доступа к тем частям API, которые разработчик класса захотел скрыть.
Начнем со случайного доступа на примере С++. Случайно в нем можно вызвать:
- конструктор (присваиванием, в контейнере при копировании, etc)
- деструктор (по выходу объекта или его владельца из области видимости)
- оператор преобразования типа
- опечатавшись, скопировав неправильно код, etc
Последний пункт скорее из области фантастики. Все остальные тоже не применимы к питону. Питон не копирует объекты, все всегда передается и хранится по ссылке, deepcopy/loads не вызывают конструктор. Деструктор вызывается непонятно когда и чаще всего его вызов сложно контролировать. Доступ к имеющиеся преобразования типов бессмысленно запрещать (__str__, __int__). Так что операции, выполняемые питоном без явного указания программиста не особо нуждаются в разграничении доступа.
Кроме того в С++ в указанных случаях мы получим ошибку на этапе компиляции, а в случае с питоном — в этапе исполнения, когда уже будет не очень понятно что с нею делать.
Перейдем к преднамеренному вызову защищенного метода. Если очень хочется, то никакой private/protected не остановит:
#define protected public
#include "foo.h"
#undef protected
Есть еще 666 способов добраться до защищенного метода. Есть они и в Java (reflections) и в C#, иначе контей