Подчеркнутая защищенность

Инкапсуляция - одна из основ ООП. Мы договариваемся использовать только часть функциональности класса, а взамен получаем возможность работать с самыми разными типами, даже с теми, которые будут написаны после окончания работы над текущим кодом.

Компилируемые языки реализуют инкапсуляцию методом принуждения. Программист отмечает методы и поля как личные или защищенные, а компилятор играет в большого брата и проверяет что все используется в корректном контексте. На моей памяти война за способ использования 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#, иначе контейнеры внедрения зависимостей не смогли бы работать.

Итого - бессмысленно защищаться и от преднамеренного вызова. Всегда есть способ обойти такую защиту. Да и если кто-то очень хочет - пусть вызывает. А для защиты от случайного вызова обычно достаточно просто не упоминать метод/поле в документации.

Документация - первая линия инкапсуляции в python.

В С++ чтение заголовочных файлов - достаточно распространенный способ получения документации и модификаторы доступа в данном случае тоже помогают. В python чтение исходников затруднено тем, что код и прототип смешаны. При желании для донесения информации до читающих исходники случая можно помечать функции декоратором, подобным этому:

Без подсветки синтаксиса

def protected(func):
    return func

class X(object):
    @protected
    def some_method(self):
        pass

def protected(func):
    return func

class X(object):
    @protected
    def some_method(self):
        pass

Наконец очень распространенный способ посмотреть что можно сделать с объектом это интроспекция. Например, если нажать <tab> после x. в ipython, то он покажет какие поля и методы есть у объекта x. Для управлением видимостью методов/полей в случае такой интроспекции в питоне есть метод __dir__:

Без подсветки синтаксиса

class X(object):
    def __dir__(self):
        return 'public_method public_field'.split()

    def __init__(self):
        self.public_field = 12
        self.protected_field = 13

    def public_method(self):
        pass

    def protected_method(self):
        pass

dir(X()) # == ['public_method', 'public_field']

class X(object):
    def __dir__(self):
        return 'public_method public_field'.split()

    def __init__(self):
        self.public_field = 12
        self.protected_field = 13

    def public_method(self):
        pass

    def protected_method(self):
        pass

dir(X()) # == ['public_method', 'public_field']

Интроспеция - вторая линия инкапсуляции в python.

Пользуйтесь этими способами и не засоряйте питон подчеркиваниями. В следующем посте мы объединим автоматизируем dir и сделаем для питона аналог private.

Ссылки:
          koder-ua.blogspot.com/2013/11/python.html

Исходники этого и других постов со скриптами лежат тут - github.com/koder-ua. При использовании их, пожалуйста, ссылайтесь на koder-ua.blogspot.com.