ООП. Дескрипторы
В этой лекции мы рассмотрим такой важный механизм как дескрипторы, а также разберемся с тем как же устроены методы класса.
Свойства
Перед тем как говорить о дескрипторах давайте еще раз поговорим о свойствах (property). Рассмотрим следующий пример: пусть у нас есть класс «Профиль пользователя», который включает следующие поля: имя, фамилия и дата рождения.
Из примера видно, что, во-первых, возраст пользователя вычисляется при каждом обращении, во-вторых, мы только получаем значение и никогда его не изменяем. Было бы логично, чтобы клиентский код работал с возрастом как с обычным атрибутом (свойством) доступным только для чтения и python предоставляет нам для этого механизм свойств (propertes):
Таким образом, свойства дают нам возможность создавать, аналогично другим языкам программирования (например, Java), сеттеры и геттеры, а также вычисляемые свойства (computed properties):
Чтобы понять как работают свойства необходимо разобраться с дескрипторами.
Дескрипторы
В документации дано следующее определение дескрипторов:
Дескриптор это любой объект, у которого определены методы __get__() , __set__() или __delete__() . Если дескриптором является атрибут класса, то для него определено специальное поведение при разшенении имени атрибута.
Дескрипторы, которые реализуют только __get__ называются дескрипторами не данных (non-data descriptors), а дескрипторы, которые реализуют __set__ и/или __delete__ называются дескрипторами данных (data descriptors). Рассмотрим следующий пример:
Из примера видно, что при обращении к d1 автоматически был вызван метод __get__ определенный на дескрипторе:
Поведением по умолчанию при доступе к атрибуту является обращение к словарю экземпляра, например, при обращении к a.x поиск начинается с a.__dict__[‘x’] , затем type(a).__dict__[‘x’] и так далее в порядке разрешения методов (mro). Когда же атрибут (класса/метакласса) является дескриптором, то Python изменяет путь поиска, сначала вызывая методы определенные у дескриптора.
Поэтому теперь должно быть понятно, почему при обращении к d2 мы получили просто экземпляр класса. Порядка разрешения имен атрибутов и методов мы коснемся в следующих лекциях.
В Python дескрипторы используются достаточно часто, в том числе и в самом языке, например, функции это дескрипторы:
Это позволяет автоматически передавать экземпляр класса в качестве первого аргумента ( self ), давайте посмотрим на вызов func_descr_get :
Если obj не был передан, то мы имеем дело с обычной функцией, в противном случае это метод и мы «биндим» объект в качестве первого аргумента. На python реализацию функций можно было бы записать так:
Руководство к дескрипторам
В этой статье я расскажу о том, что такое дескрипторы, о протоколе дескрипторов, покажу как вызываются дескрипторы. Опишу создание собственных и исследую несколько встроенных дескрипторов, включая функции, свойства, статические методы и методы класса. С помощью простого приложения покажу, как работает каждый из них, приведу эквиваленты внутренней реализации работы дескрипторов кодом на чистом питоне.
Изучение того, как работают дескрипторы, откроет доступ к большему числу рабочих инструментов, поможет лучше понять как работает питон, и ощутить элегантность его дизайна.
Введение и определения
Если говорить в общем, то дескриптор — это атрибут объекта со связанным поведением (англ. binding behavior), т.е. такой, чьё поведение при доступе переопределяется методами протокола дескриптора. Эти методы: __get__ , __set__ и __delete__ . Если хотя бы один из этих методов определён для объекта, то он становится дескриптором.
Стандартное поведение при доступе к атрибутам — это получение, установка и удаление атрибута из словаря объекта. Например, a.x имеет такую цепочку поиска атрибута: a.__dict__[‘x’] , затем в type(a).__dict__[‘x’] , и далее по базовым классам type(a) не включая метаклассы. Если же искомое значение — это объект, в котором есть хотя бы один из методов, определяющих дескриптор, то питон может изменить стандартную цепочку поиска и вызвать один из методов дескриптора. Как и когда это произойдёт зависит от того, какие методы дескриптора определены для объекта. Дескрипторы вызываются только для объектов или классов нового стиля (класс является таким, если наследует от object или type ).
Дескрипторы — это мощный протокол с широкой областью применения. Они являются тем механизмом, который стоит за свойствами, методами, статическими методами, методами класса и вызовом super() . Внутри самого питона с их помощью реализуются классы нового стиля, которые были представлены в версии 2.2. Дескрипторы упрощают понимание нижележащего кода на C, а также представляют гибкий набор новых инструментов для любых программ на питоне.
Протокол дескрипторов
Собственно это всё. Определите любой из этих методов и объект будет считаться дескриптором, и сможет переопределять стандартное поведение, если его будут искать как атрибут.
Если объект определяет сразу и __get__ , и __set__ , то он считается дескриптором данных (англ. data descriptor). Дескрипторы, которые определили только __get__ называются дескрипторами не данных (англ. non-data descriptors). Их называются так, потому что они используют для методов, но другие способы их применения также возможны.
Дескрипторы данных и не данных отличаются в том, как будет изменено поведение поиска, если в словаре объекта уже есть запись с таким же именем как у дескриптора. Если попадается дескриптор данных, то он вызывается раньше, чем запись из словаря объекта. Если в такой же ситуации окажется дескриптор не данных, то запись из словаря объекта имеет преимущество перед этим дескриптором.
Чтобы создать дескриптор данных только для чтения, определите и __get__ , и __set__ , и сделайте так, чтобы __set__ выбрасывал исключение AttributeError . Определения метода __set__ и выбрасывания исключения достаточно, чтобы этот дескриптор считался дескриптором данных.
Вызов дескрипторов
Дескриптор можно вызвать напрямую через его метод. Например, d.__get__(obj) .
Однако, наиболее частый вариант вызова дескриптора — это автоматический вызов во время доступа к атрибуту. Например, obj.d ищет d в словаре obj . Если d определяет метод __get__ , то будет вызван d.__get__(obj) . Вызов будет сделан согласно правилам, описанным ниже.
Детали вызова различаются от того, чем является obj — объектом или классом. В любом случае, дескрипторы работают только для объектов и классов нового стиля. Класс является классом нового стиля, если он является потомком object .
Для объектов алгоритм реализуется с помощью object.__getattribute__ , который преобразует запись b.x в type(b).__dict__[‘x’].__get__(b, type(b)) . Реализация работает через цепочку предшественников, в которой дескрипторы данных имеют приоритет перед переменными объекта, переменные объекта имеют приоритет перед дескрипторами не данных, и самый низкий приоритет у метода __getattr__ , если он определён. Полную реализацию на языке C можно найти в PyObject_GenericGetAttr() в файле Objects/object.c .
Для классов алгоритм реализуется с помощью type.__getattribute__ , который преобразует запись B.x в B.__dict__[‘x’].__get__(None, B) . На чистом питоне это выглядит так:
- дескрипторы вызываются с помощью метода __getattribute__
- переопределение __getattribute__ прекратит автоматический вызов дескрипторов
- __getattribute__ доступен только внутри классов и объектов нового стиля
- object.__getattribute__ и type.__getattribute__ делают разные вызовы к __get__
- дескрипторы данных всегда имеют преимущество перед переменными объекта
- дескрипторы не данных могут потерять преимущество из-за переменных объекта
Примечание: в питоне 2.2, super(B, obj).m() вызывал __get__ только если m был дескриптором данных. В питоне 2.3, дескрипторы не данных тоже вызываются, за исключением тех случаев, когда используются классы старого стиля. Детали реализации можно найти в super_getattro() в файле Objects/typeobject.c , а эквивалент на чистом питоне можно найти в пособии от Guido.
Детали выше описывают, что алгоритм вызова дескрипторов реализуется с помощью метода __getattribute__() для object , type и super . Классы наследуют этот алгоритм, когда они наследуют от object или если у них есть метакласс, реализующий подобную функциональность. Таким образом, классы могут отключить вызов дескрипторов, если переопределят __getattribute__() .
Пример дескриптора
Следующий код создаёт класс, чьи объекты являются дескрипторам данных и всё, что они делают — это печатают сообщение на каждый вызов get или set . Переопределение __getattribute__ — это альтернативный подход, с помощью которого мы могли бы сделать это для каждого атрибута. Но если мы хотим наблюдать только за отдельными атрибутами, то это проще сделать с помощью дескриптора.
Этот простой протокол предоставляет просто увлекательные возможности. Некоторые из них настолько часто используются, что были объединены в отдельные функции. Свойства, связанные и несвязанные методы, статические методы и методы класса — все они основаны на этом протоколе.
Свойства
Вызова property() достаточно, чтобы создать дескриптор данных, который вызывает нужные функции во время доступа к атрибуту. Вот его сигнатура:
В документации показано типичное использование property() для создания управляемого атрибута x :
Вот эквивалент property на чистом питоне, чтобы было понятно как реализовано property() с помощью протокола дескрипторов:
Встроенная реализация property() может помочь, когда существовал интерфейс доступа к атрибуту и произошли какие-то изменения, в результате которых понадобилось вмешательство метода.
Например, класс электронной таблицы может давать доступ к значению ячейки через Cell(‘b10’).value . В результате последующих изменений в программе, понадобилось сделать так, чтобы это значение пересчитывалось при каждом доступе к ячейке, однако программист не хочет менять клиентский код, который обращается к атрибуту напрямую. Эту проблему можно решить, если обернуть атрибут value с помощью дескриптора данных, который будет создан с помощью property() :
Функции и методы
В питоне все объектно-ориентированные возможности реализованы с помощью функционального подхода. Это сделано совсем незаметно с помощью дескрипторов не данных.
Словари классов хранят методы в виде функций. При определении класса, методы записываются с помощью def и lambda — стандартных инструментов для создания функций. Единственное отличие этих функций от обычных в том, что первый аргумент зарезервирован под экземпляр объекта. Этот аргумент обычно называется self , но может называться this или любым другим словом, которым можно называть переменные.
Для того, чтобы поддерживать вызов методов, функции включают в себя метод __get__ , который автоматически делает их дескрипторами не данных при поиске атрибутов. Функции возвращают связанные или не связанные методы, в зависимости от того, через что был вызван этот дескриптор.
С помощью интерпретатора мы можем увидеть как на самом деле работает дескриптор функции:
Вывод интерпретатора подсказывает нам, что связанные и несвязанные методы — это два разных типа. Даже если они могли бы быть реализованы таким образом, на самом деле, реализация PyMethod_Type в файле Objects/classobject.c содержит единственный объект с двумя различными отображениями, которые зависят только от того, есть ли в поле im_self значение или там содержится NULL (C эквивалент значения None ).
Таким образом, эффект вызова метода зависит от поля im_self . Если оно установлено (т.е. метод связан), то оригинальная функция (хранится в поле im_func ) вызывается, как мы и ожидаем, с первым аргументом, установленным в значение экземпляра объекта. Если же она не связана, то все аргументы передаются без изменения оригинальной функции. Настоящая C реализация instancemethod_call() чуть более сложная, потому что включает в себя некоторые проверки типов и тому подобное.
Статические методы и методы класса
Дескрипторы не данных предоставляют простой механизм для различных вариантов привязки функций к методам.
Повторим ещё раз. Функции имеют метод __get__ , с помощью которых они становятся методами, во время поиска атрибутов и автоматического вызова дескрипторов. Дескрипторы не данных преобразуют вызов obj.f(*args) в вызов f(obj, *args) , а вызов klass.f(*args) становится f(*args) .
В этой таблице показано связывание и два наиболее популярных варианта:
| Преобразование | Вызвана через объект | Вызвана через класс | |
|---|---|---|---|
| Дескриптор | функция | f(obj, *args) | f(*args) |
| staticmethod | f(*args) | f(*args) | |
| classmethod | f(type(obj), *args) | f(klass, *args) | |
Статические методы возвращают функцию без изменений. Вызовы c.f или C.f эквиваленты вызовам object.__getattribute__(c, «f») или object.__getattribute__(C, «f») . Как результат, функция одинаково доступна как из объекта, так и из класса.
Хорошими кандидатами для статических методов являются методы, которым не нужна ссылка на переменную self .
Например, пакет для статистики может включать класс для экспериментальных данных. Класс предоставляет обычные методы для расчёта среднего, ожидания, медианы и другой статистики, которая зависит от данных. Однако, там могут быть и другие функции, которые концептуально связаны, но не зависят от данных. Например, erf(x) это простая функция для преобразования, которая нужна в статистике, но не зависит от конкретного набора данных в этом классе. Она может быть вызвана и из объекта, и из класса: s.erf(1.5) —> 0.9332 или Sample.erf(1.5) —> 0.9332 .
Так как staticmethod() возвращает функцию без изменений, то этот пример не удивляет:
Если использовать протокол дескриптора не данных, то на чистом питоне staticmethod() выглядел бы так:
В отличие от статических методов, методы класса подставляют в начало вызова функции ссылку на класс. Формат вызова всегда один и тот же, и не зависит от того, вызываем мы метод через объект или через класс.
Это поведение удобно, когда нашей функции всегда нужна ссылка на класс и ей не нужны данные. Один из способов использования classmethod() — это создание альтернативных конструкторов класса. В питоне 2.3, метод класса dict.fromkeys() создаёт новый словарь из списка ключей. Эквивалент на чистом питоне будет таким:
Теперь новый словарь уникальных ключей можно создать таким образом:
Если использовать протокол дескриптора не данных, то на чистом питоне classmethod() выглядел бы так:
Дескрипторы в C++
Итак, после небольшого подогрева умные указатели превратились в ведущие. Теперь в нашем вареве появляется еще один ингредиент — дескрипторы (handles) C++. Не путайте этот термин с дескрипторами, используемыми в операционных системах Macintosh и Windows. Некоторое сходство существует, но идиома дескрипторов C++ имеет собственную уникальную семантику и набор правил.
Основная идея заключается в том, чтобы использовать умные указатели для ссылок на ведущие указатели. Эти дополнительные указатели и называются дескрипторами. Основа, на которой мы будем строить класс дескрипторов, в первом приближении выглядит так:
template <class Type>
// Ссылка на ведущий указатель
Безаргументный конструктор Н создает новый ведущий указатель. Этот ведущий указатель, в свою очередь, создает указываемый объект. Существует второй конструктор, который получает ведущий указатель и инициализирует им переменную ptr . Конструктор копий и оператор = по умолчанию годятся, поскольку любому ведущему указателю может соответствовать несколько дескрипторов. Работа оператора -> основана на рекурсивном алгоритме, используемом компилятором: оператор -> дескриптора возвращает ведущий указатель; затем оператор -> ведущего указателя возвращает указатель Type* который является одним из базовых типов компилятора.
Приведенное решение не назовешь изящным — вложенные шаблоны порождают путаницу, к тому же совершенно неясно, когда и как удалять ведущие указатели. Кроме того, следует ли разрешить пользователю напрямую создавать и уничтожать ведущие указатели или же заключить их внутри дескрипторов так, как мы заключили указываемые объекты внутри ведущих указателей? Неужели мы трудились над решением этих проблем для указываемых объектов лишь затем, чтобы столкнуться с ними снова для ведущих указателей? Терпение — в свое время мы найдем ответ на эти и многие другие вопросы.
Что же получается?
Мы начнем с простого примера ведущих указателей и усовершенствуем его до уровня, который удовлетворил бы и более требовательную аудиторию. На этой стадии еще трудно понять всю пользу дескрипторов, но в следующих главах они будут играть очень важную роль.
Подсчет объектов
Допустим, вы хотите следить за количеством созданных или находящихся в памяти объектов некоторого класса. Одно из возможных решений — хранить эти сведения в статических переменных самого класса.
static int current; public:
CountedStuff() < current++; >CountedStuff(const CuntedStuff&) < current++; >CountedStuff& operator=(const CountedStuff&)
<> // Не менять счетчик для присваивания
С этим примером еще можно повозиться и улучшить его, но как бы вы ни старались, придется изменять код целевого класса — хотя бы для того, чтобы заставить его наследовать от нашего класса. Теперь предположим, что указываемый объект входит в коммерческую библиотеку. Обидно, да? Любые изменения нежелательны, а скорее всего, просто невозможны. Но вот на сцену выходит класс ведущего указателя.
template <class Type> class CMP <
static int current; Type* ptr;
CMP() : ptr(new Type)
CMP(const CMP<Type>& cmp) : ptr(new Type(*(mp.t))) < current++; >CMP<Type>& operator=(const CMP<Type>& cmp)
ptr = new Type(*(cmp.ptr));
Type* operator->() const < return ptr; >Static int Current()
Теперь ведущий указатель выполняет все подсчеты за вас. Он не требует внесения изменений в класс указываемого объекта. Этот шаблон может использоваться для любого класса при условии, что вам удастся втиснуть ведущие указатели между клиентом и указываемым объектом. Даже если вы не возражаете против модификации исходного класса указываемого объекта, обеспечить такой уровень модульности без ведущих указателей было бы крайне сложно (например, если бы вы попытались действовать через базовый класс, то в результате получили бы одну статическую переменную current на все производные классы).
Этот пример тривиален, но даже он демонстрирует важный принцип программирования на C++, справедливость которого со временем становится очевидной: пользуйтесь умными указателями, даже если сначала кажется, что они не нужны. Если программа написана для умных указателей, все изменения вносятся легко и быстро. Если же вам придется переделывать готовую программу и заменять все операторы * умными указателями, приготовьтесь к ночным бдениям.
В главе 14 вариации на тему подсчета будут использованы для реализации простой, но в то же время мощной схемы управления памятью — сборки мусора с подсчетом ссылок.
Указатели только для чтения
Предположим, вы хотите сделать так, чтобы некоторый объект никогда не обновлялся (или, по крайней мере, не обновлялся обычными клиентами). Эта задача легко решается с помощью ведущих указателей
— достаточно сделать операторную функцию operator->() константной функцией класса.
template <class Type>
// Создает указываемый объект
// Копирует указываемый объект
// Удаляет указываемый объект
ROMP<Type>& operator=(const ROMP<Type>&); const Type* operator->() const;
Указываемый объект заперт так надежно, что до него не доберется даже ЦРУ. В принципе, то же самое можно было сделать с помощью более простых умных указателей, но ведущие указатели обеспечивают стопроцентную защиту, так как клиент никогда не получает прямого доступа к указываемому объекту.
Указатели для чтения/записи
Во многих ситуациях существует оптимальное представление объекта, которое действительно лишь для операций чтения. Если клиент хочет изменить объект, представление приходится изменять.
Это было бы легко сделать при наличии двух перегруженных версий оператора -> , одна из которых возвращает Foo* , а другая — const Foo* . К сожалению, разные возвращаемые типы не обеспечивают уникальности сигнатур, поэтому при попытке объявить два оператора -> компилятор от души посмеется. Программисту придется заранее вызвать функцию, которая осуществляет переход от одного представления к другому.
Одно из возможных применений этой схемы — распределенные объекты. Если копии объекта не обновляются локальными клиентами, они могут быть разбросаны по всей сети. Совсем другое дело — координация обновлений нескольких экземпляров. Можно установить правило, согласно которому допускается существование любого количества копий только для чтения, но лишь одна главная копия. Чтобы обновить объект, необходимо предварительно получить главную копию у ее текущего владельца. Конечно, приходится учитывать многие нюансы (в частности, процедуру смены владельца главной копии), однако правильное применение ведущих указателей позволяет реализовать эту концепцию на удивление просто и незаметно для клиентов.
Дескриптор (вычисление) — Handle (computing)
В компьютерном программировании дескриптор является abstract ссылка на ресурс, который используется, когда прикладное программное обеспечение ссылается на блоки памяти или объекты, которые управляются другой системой, например база данных или операционная система.
Дескриптор ресурса может быть непрозрачным идентификатором, и в этом случае это часто целое число число (часто индекс массива в массиве или «таблице», который используется для управления этим типом ресурса), или это может быть указатель , который позволяет получить доступ к дополнительной информации. Обычные дескрипторы ресурсов включают дескрипторы файлов, сетевые сокеты, соединения с базой данных, идентификаторы процессов (PID) и идентификаторы заданий. PID и идентификаторы заданий — это явно видимые целые числа; в то время как файловые дескрипторы и сокеты (которые часто реализуются как форма файлового дескриптора) представлены как целые числа, они обычно считаются непрозрачными. В традиционных реализациях файловые дескрипторы представляют собой индексы в (для каждого процесса) таблице файловых дескрипторов, а затем в (общесистемной) файловой таблице.
Содержание
- 1 Сравнение с указателями
- 2 Безопасность
- 3 Примеры
- 4 См. Также
- 5 Ссылки
- 6 Внешние ссылки
Сравнение с указателями
Хотя указатель содержит адрес элемента, на который он ссылается, дескриптор — это абстракция ссылки, которая управляется извне; его непрозрачность позволяет системе перемещать референт в памяти без аннулирования дескриптора, что невозможно с указателями. Дополнительный уровень косвенного обращения также увеличивает контроль, который система управления имеет над операциями, выполняемыми над референтом. Обычно дескриптор является индексом или указателем на глобальный массив надгробий.
A дескриптор утечки — это тип программной ошибки, которая возникает, когда компьютерная программа запрашивает дескриптор для ресурс, но не освобождает дескриптор, когда он больше не используется; это форма утечки ресурсов, аналогичная утечке памяти для указателя на память.
Безопасность
В терминах безопасных вычислений, поскольку доступ к ресурсу через дескриптор опосредован другой системой, дескриптор функционирует как возможность : он не только идентифицирует объект, но и связывает права доступа. Например, хотя имя файла можно подделать (это просто угадываемый идентификатор), дескриптор присваивается пользователю внешней системой и, таким образом, представляет собой не только личность, но и предоставленный доступ.
Например, если программа хочет прочитать файл системного пароля ( / etc / passwd ) в режиме чтения / записи ( O_RDWR ), она может попытаться откройте файл с помощью следующего вызова:
Этот вызов просит операционную систему открыть указанный файл с указанными правами доступа. Если ОС позволяет это сделать, она открывает файл (создает запись в таблице дескрипторов файла для каждого процесса ) и возвращает дескриптор (дескриптор файла, индекс в этой таблице) пользователю: фактический доступ управляется ОС, и дескриптор является токеном этого. И наоборот, ОС может запретить доступ и, таким образом, не открыть файл и не вернуть дескриптор.
В системе, основанной на возможностях, дескрипторы могут передаваться между процессами с соответствующими правами доступа. Обратите внимание, что в этих случаях дескриптор должен быть чем-то другим, кроме уникального для всей системы небольшого целого числа, в противном случае его можно подделать. Тем не менее такое целое число может использоваться для идентификации возможности внутри процесса; например, файловый дескриптор в Linux невозможно подделать, потому что одно его числовое значение не имеет смысла и только в контексте процесса может относиться к чему угодно. Однако передача такого дескриптора требует особой осторожности, поскольку его значение часто должно быть различным в процессах отправки и получения.
В системах, не основанных на возможностях, с другой стороны, каждый процесс должен получить свой собственный отдельный дескриптор, указав идентификатор ресурса и желаемые права доступа (например, каждый процесс должен сам открывать файл, указав имя файла и режим доступа). Такое использование более распространено даже в современных системах, которые поддерживают передачу дескрипторов, но оно подвержено уязвимостям, таким как проблема запутанного заместителя.
Примеры
Дескрипторы были популярным решением для управления памятью. в операционных системах 1980-х годов, таких как Mac OS и Windows. Структура данных FILE в стандартной библиотеке ввода-вывода C — это дескриптор файла, абстрагирующийся от базового представления файла (в Unix это файл дескрипторы ). Подобно другим средам рабочего стола, Windows API широко использует дескрипторы для представления объектов в системе и обеспечения канала связи между операционной системой и пользовательским пространством. Например, окно на рабочем столе представлено дескриптором типа HWND (дескриптор, окно).
Двойные косвенные дескрипторы в последнее время потеряли популярность, поскольку увеличение доступной памяти и улучшенные алгоритмы виртуальной памяти сделали использование более простого указателя более привлекательным. Однако во многих операционных системах этот термин по-прежнему применяется к указателям на непрозрачные, «частные» структуры данных — непрозрачные указатели — или на индексы во внутренние массивы, переданные от одного процесса на его клиент.