Что такое mixin python
Что такое миксины в Python и как их использовать.
В Python нет какого либо специального синтаксиса для поддержки миксинов, по этому классы миксинов, легко можно перепутать с обычными классами, но при этом у них действительно очень большая как семантическая, так и реальная разница с обычными классами.
Так как для реализации поведения миксинов используется простое множественное наследование, то это требует от программиста большой дисциплины, поскольку нарушает одно из основных допущений для миксинов: их ортогональность к дереву наследования, т. е. классы, не зависят друг от друга. В Python миксины живут в обычном дереве наследования, предоставляя дополнительную функциональность и избегают создания иерархий, которые слишком сложны для понимания программистом.
Пример множественного наследования.
Пример использования класса миксина/примеси.
В отличие от приведенного выше примера, класс миксина не предназначен для использования отдельно. Он предоставляет новые методы или переопределяет имеющиеся методы.
Например, в стандартной библиотеке Python, в модуле socketserver есть несколько миксинов. Выдержка из документации:
С помощью этих классов миксинов могут быть созданы поточные версии каждого типа сервера. Например, ThreadingUDPServer создается следующим образом:
Простой пример для понимания поведения классов миксинов.
Иногда молодые программисты не до конца понимают принцип MRO в Python и по этому в некоторых случаях не правильно используют классы миксинов.
Русские Блоги
Понимание концепций Mixin через Python
Концепция Миксин
Используя множественное наследование Python, подклассы могут наследовать классы Mixin различных функций и динамически объединять их по мере необходимости.
Когда несколько классов реализовали одну и ту же функцию, эту функцию следует рассматривать как класс Mixin.
например
Определите простой класс:
Мы можем получить к нему доступ, вызвав свойства экземпляра:
Затем мы определяем класс Mixin:
Этот класс позволяет подклассам иметь возможность вызывать такие атрибуты, как dict
Мы добавляем этот Mixin в класс Person:
Теперь у Person есть еще один способ вызова атрибутов:
Затем определите класс Mixin, этот класс реализует __repr__ Метод, может автоматически объединять атрибуты и значения в строку:
Используя возможности Python, класс может наследовать несколько родительских классов:
Этот подкласс смешивает две функции:
подводить итоги
Mixin по существу использует языковые функции и может рассматриваться как особый вид множественного наследования, поэтому он не является эксклюзивным для Python, если он поддерживает множественное наследование или аналогичные функции, такие как синтаксис include в Ruby, Vue и других интерфейсных полях. Существует также концепция Mixin.
Тем не менее, Mixin не относится к грамматике языка.Для удобства чтения и поддержки кода, определение и использование класса Mixin должны следовать нескольким принципам:
1. Функции, реализуемые Mixin, должны быть универсальными и единичными. Например, два класса Mixin в приведенном выше примере подходят для большинства подклассов. Каждый Mixin реализует только одну функцию и может наследоваться при необходимости. 2. Mixin используется только для расширения функций подклассов, он не может влиять на основные функции подклассов, и подклассы не могут полагаться на Mixin. Например, в приведенном выше примере Person ¡Наследование разных миксов просто добавляет некоторые функции и не влияет на его основные функции. Если это зависимость, то это реальный базовый класс, и его не следует называть в честь Mixin. 3. Сам класс Mixin не может быть создан, он используется только для наследования подклассами.
Рекомендуемое чтение
Сканирование кода ответа: анализ данных
Получите 38g учебные ресурсы по анализу данных
Как статья, заказ смотреть в
На этом занятии мы с вами вынесем общий код классов представлений в отдельный класс, который можно воспринимать как миксин (mixin). Те из вас, кто хорошо знаком с ООП уже знают, что такое миксины и для чего они служат. Но я все же сделаю небольшую ремарку и подробнее поясню этот момент.
Для материальных товаров все эти характеристики имеют смысл:
Но для информационных, таких как электронная книга или приложение для смартфона, габариты и вес не определены. Тем не менее, система магазина в целом, обращается к этим свойствам объектов (товаров). Как сделать так, чтобы каждый объект, представляющий товар, имел по умолчанию все нужные свойства? Конечно, мы можем непосредственно в классе их прописать:
Но это начинает плохо работать, при наличии разветвленной иерархии объектов, когда каждый класс товара представляется отдельным классом:
Тогда пришлось бы в каждом прописывать эти методы, что нехорошо. Поэтому, как вы уже догадались, все это выносится в базовый класс, например, Goods. Но, иногда, наборы разрозненных классов не имеют единого базового, либо базовый класс находится на таком уровне абстракции, что в него писать такие конкретные методы – прямой путь к мешанине кода. Вот как раз для таких случаев, когда нужно дополнительно к уже существующей иерархии добавить какие-либо общие для разнородных классов данные и/или методы и применяется механизм миксинов.
В разных языках программирования миксины реализуются по разному. В частности, в Python, благодаря наличию механизма множественного наследования, примеси можно добавлять в виде отдельного базового класса:
Например, наши классы представлений можно дополнительно унаследовать от класса DataMixin, который мы отдельно определим. Причем, этот класс лучше прописывать первым в списке наследования:
Так как в нем могут быть атрибуты и методы, которые, затем, используются конструктором следующего класса – ListView. То есть, в Python, класс, записанный первым, первым и обрабатывается. Поэтому данные базового класса DataMixin переопределят (при необходимости) атрибуты следующего класса ListView.
Давайте теперь определим наш класс DataMixin и уберем дублирование кода из классов представлений. Первый вопрос, где прописать этот класс? Обычно, в Django все дополнительные, вспомогательные классы объявляют в отдельном файле приложения utils.py. Мы так и поступим. Создадим этот файл и в нем запишем класс DataMixin, следующим образом:
Обратите внимание, я перенес сюда и главное меню, т.к. оно используется напрямую классом DataMixin. И вначале идет импорт моделей, т.к. мы используем класс Category для получения всех категорий.
Если вы помните, мы категории в шаблоне base.html сейчас отображаем с помощью созданного нами тега show_categories. Это был искусственный пример, демонстрирующий возможность создания пользовательских тегов, теперь я его уберу и вместо него буду использовать переменную cats, которую передадим в шаблон. Соответственно, в шаблоне вернем строчки для отображения рубрик:
Итак, что же делает класс DataMixin? Смотрите, в нем объявлен вспомогательный метод get_user_context() для формирования контекста шаблона по умолчанию. Также, при необходимости, мы можем передавать ему именованные аргументы, которые также будут помещаться в контекст. Благодаря этому методу, нам не придется в классах представлений каждый раз прописывать ссылки на главное меню и категории.
Итак, класс миксин объявлен, осталось прописать его в качестве базового у классов представлений. Для этого в файле views.py мы импортируем модуль utils.py:
И унаследуем класс WomenHome также и от DataMixin:
Осталось изменить метод get_context_data(), следующим образом:
Смотрите, мы здесь вызываем метод get_user_context() класса DataMixin, указав, дополнительно параметр title. Получаем сформированный словарь c_def со всеми стандартными ключами и объединяем его со словарем context. В конце, возвращаем объединенные данные. Все, дублирование в методе get_context_data() устранено.
По аналогии, меняем и все остальные классы представлений:
Все, переходим на сайт и видим, что страницы отображаются также как и ранее, но теперь все работает совместно с классом DataMixin. Вот пример того, как миксины в Django позволяют устранять дублирование кода в классах представлений.
Конечно, в класс DataMixin можно прописывать не только методы, но и общие атрибуты, если они есть, то есть, выносить любую общую информацию.
Миксины фреймворка Django
В Django есть стандартные миксины, которые можно использовать совместно с классами представлений. Использовать их достаточно просто, я покажу пример одного такого миксина:
который позволяет ограничить доступ к странице для неавторизованных пользователей. Подробную информацию об этом классе можно посмотреть по этой ссылке:
Давайте вначале выполним его импорт в файле views.py:
А, затем, добавим в класс AddPage:
Причем, прописывать желательно самым первым, т.к. он имеет наибольшую важность. Хотя, в нашем случае первые два миксина можно записывать в любом порядке, они никак между собой не пересекаются.
По идее все. Если теперь попробовать выйти из админки (то есть, стать не зарегистрированным пользователем) и перейти на добавление поста, то увидим страницу с кодом 404. Давайте улучшим этот поведение, сделаем его более дружественным. Для этого, в классе AddPage (после добавления миксина LoginRequiredMixin) можно прописать специальный атрибут:
который указывает адрес перенаправления для незарегистрированного пользователя. В данном случае, мы его отправляем в админ-панель. Переходим на главную страницу, затем, на добавление статьи и автоматом перенаправляемся на форму авторизации.
Конечно, прописывать конкретный URL-адрес – это не лучшая практика, поэтому, давайте, воспользуемся функцией reverse_lazy для формирования маршрута по его имени:
Также, вместо перенаправлений, можно генерировать страницу с кодом 403 – доступ запрещен. Для этого достаточно прописать атрибут:
Если похожий функционал нужно реализовать для функций представлений, а не классов, то здесь уже используется декоратор login_required, например, так:
Теперь эта страница доступна только авторизованным пользователям. Я уберу его, т.к. он здесь не к месту. Это просто демонстрация того, как ограничить доступ, работая с функциями представлениями.
Наконец, давайте сделаем отображение пункта «Добавить статью» только для авторизованных пользователей. Для этого я в классе DataMixin буду удалять этот пункт, если пользователь не авторизован:
Здесь используется объект request, у которого имеется объект user, а у того, в свою очередь, специальный булевый атрибут is_authenticated, указывающий на авторизацию текущего пользователя (если True – авторизован, False – в противном случае). Подробнее об этом также можно посмотреть на странице:
Ну и в заключение этого занятия, давайте сделаем вывод только тех рубрик, которые содержат статьи. Для этого мы будем выбирать рубрики с использованием агрегирующей функции:
Как работает эта строчка мы говорили на предыдущем занятии. Далее, в шаблоне base.html пропишем проверку при выводе рубрик:
Все, теперь у нас появляются только те рубрики, у которых есть статьи, что более логично.
Видео по теме
#2. Модель MTV. Маршрутизация. Функции представления
#3. Маршрутизация, обработка исключений запросов, перенаправления
#4. Определение моделей. Миграции: создание и выполнение
#6. Шаблоны (templates). Начало
#7. Подключение статических файлов. Фильтры шаблонов
#8. Формирование URL-адресов в шаблонах
#9. Создание связей между моделями через класс ForeignKey
#10. Начинаем работу с админ-панелью
#11. Пользовательские теги шаблонов
#12. Добавляем слаги (slug) к URL-адресам
#13. Использование форм, не связанных с моделями
#14. Формы, связанные с моделями. Пользовательские валидаторы
#15. Классы представлений: ListView, DetailView, CreateView
#16. Основы ORM Django за час
#18. Постраничная навигация (пагинация)
#19. Регистрация пользователей на сайте
#20. Делаем авторизацию пользователей на сайте
#21. Оптимизация сайта с Django Debug Toolbar
#22. Включаем кэширование данных
#23. Использование капчи captcha
#24. Тонкая настройка админ панели
#25. Начинаем развертывание Django-сайта на хостинге
#26. Завершаем развертывание Django-сайта на хостинге
© 2021 Частичное или полное копирование информации с данного сайта для распространения на других ресурсах, в том числе и бумажных, строго запрещено. Все тексты и изображения являются собственностью сайта
What is a mixin, and why are they useful?
In «Programming Python», Mark Lutz mentions «mixins». I’m from a C/C++/C# background and I have not heard the term before. What is a mixin?
Reading between the lines of this example (which I’ve linked to because it’s quite long), I’m presuming it’s a case of using multiple inheritance to extend a class as opposed to ‘proper’ subclassing. Is this right?
Why would I want to do that rather than put the new functionality into a subclass? For that matter, why would a mixin/multiple inheritance approach be better than using composition?
What separates a mixin from multiple inheritance? Is it just a matter of semantics?
16 Answers 16
A mixin is a special kind of multiple inheritance. There are two main situations where mixins are used:
For an example of number one, consider werkzeug’s request and response system. I can make a plain old request object by saying:
If I want to add accept header support, I would make that
If I wanted to make a request object that supports accept headers, etags, authentication, and user agent support, I could do this:
First, you should note that mixins only exist in multiple-inheritance languages. You can’t do a mixin in Java or C#.
Basically, a mixin is a stand-alone base type that provides limited functionality and polymorphic resonance for a child class. If you’re thinking in C#, think of an interface that you don’t have to actually implement because it’s already implemented; you just inherit from it and benefit from its functionality.
Mixins are typically narrow in scope and not meant to be extended.
I suppose I should address why, since you asked. The big benefit is that you don’t have to do it yourself over and over again. In C#, the biggest place where a mixin could benefit might be from the Disposal pattern. Whenever you implement IDisposable, you almost always want to follow the same pattern, but you end up writing and re-writing the same basic code with minor variations. If there were an extendable Disposal mixin, you could save yourself a lot of extra typing.
What separates a mixin from multiple inheritance? Is it just a matter of semantics?
Yes. The difference between a mixin and standard multiple inheritance is just a matter of semantics; a class that has multiple inheritance might utilize a mixin as part of that multiple inheritance.
The point of a mixin is to create a type that can be «mixed in» to any other type via inheritance without affecting the inheriting type while still offering some beneficial functionality for that type.
Again, think of an interface that is already implemented.
Suppose you have a type that you want to be able to serialize to and from XML. You want the type to provide a «ToXML» method that returns a string containing an XML fragment with the data values of the type, and a «FromXML» that allows the type to reconstruct its data values from an XML fragment in a string. Again, this is a contrived example, so perhaps you use a file stream, or an XML Writer class from your language’s runtime library. whatever. The point is that you want to serialize your object to XML and get a new object back from XML.
The other important point in this example is that you want to do this in a generic way. You don’t want to have to implement a «ToXML» and «FromXML» method for every type that you want to serialize, you want some generic means of ensuring that your type will do this and it just works. You want code reuse.
If your language supported it, you could create the XmlSerializable mixin to do your work for you. This type would implement the ToXML and the FromXML methods. It would, using some mechanism that’s not important to the example, be capable of gathering all the necessary data from any type that it’s mixed in with to build the XML fragment returned by ToXML and it would be equally capable of restoring that data when FromXML is called.
And.. that’s it. To use it, you would have any type that needs to be serialized to XML inherit from XmlSerializable. Whenever you needed to serialize or deserialize that type, you would simply call ToXML or FromXML. In fact, since XmlSerializable is a fully-fledged type and polymorphic, you could conceivably build a document serializer that doesn’t know anything about your original type, accepting only, say, an array of XmlSerializable types.
Now imagine using this scenario for other things, like creating a mixin that ensures that every class that mixes it in logs every method call, or a mixin that provides transactionality to the type that mixes it in. The list can go on and on.
If you just think of a mixin as a small base type designed to add a small amount of functionality to a type without otherwise affecting that type, then you’re golden.
Что такое миксин и почему они полезны?
В «программировании Python» Марк Лутц упоминает «миксины». Я из C / C ++ / C # фона, и я не слышал этот термин раньше. Что такое миксин?
Чтение между строками этот пример (с которым я связался, потому что он довольно длинный), я предполагаю, что это случай использования множественного наследования для расширения класса в отличие от «правильного» подкласса. Это правильно?
Почему я хотел бы сделать это, а не помещать новую функциональность в подкласс? В этом отношении, почему подход смешанного / множественного наследования лучше, чем использование композиции?
Что отличает миксин от множественного наследования? Это просто вопрос семантики?
14 ответов
Для примера номер один рассмотрим систему запросов и ответов werkzeug. Я могу сделать простой старый объект запроса, сказав:
Если я хочу добавить поддержку заголовка принять, я бы сделал это
Если бы я хотел создать объект запроса, который поддерживает заголовки принятия, etags, аутентификацию и поддержку агента пользователя, я мог бы сделать это:
Во-первых, вы должны заметить, что миксины существуют только в языках множественного наследования. Вы не можете сделать миксин в Java или C #.
Миксины обычно узкие по объему и не предназначены для расширения.
Что отличает миксин от множественного наследования? Это просто вопрос семантики?
Да. Разница между миксином и стандартным множественным наследованием является лишь вопросом семантики; класс с множественным наследованием может использовать миксин как часть этого множественного наследования.
Смысл mixin состоит в том, чтобы создать тип, который можно «смешать» с любым другим типом посредством наследования, не затрагивая наследующий тип, и в то же время предлагать некоторые полезные функции для этого типа.
Опять же, подумайте об интерфейсе, который уже реализован.
Другим важным моментом в этом примере является то, что вы хотите сделать это в общем виде. Вам не нужно реализовывать методы «ToXML» и «FromXML» для каждого типа, который вы хотите сериализовать, вам нужны некоторые общие средства, гарантирующие, что ваш тип будет делать это, и он просто работает. Вы хотите повторного использования кода.
Если ваш язык поддерживает это, вы можете создать миксин XmlSerializable, который сделает вашу работу за вас. Этот тип будет реализовывать методы ToXML и FromXML. Используя некоторый механизм, который не важен для примера, он мог бы собрать все необходимые данные из любого типа, с которым он смешан, для создания фрагмента XML, возвращаемого ToXML, и он был бы в равной степени способен восстанавливать эти данные, когда FromXML называется.
Вот и все. Чтобы использовать его, вы должны иметь любой тип, который нужно сериализовать, чтобы XML наследовал от XmlSerializable. Когда бы вам ни понадобилось сериализовать или десериализовать этот тип, вы просто вызывали бы ToXML или FromXML. Фактически, поскольку XmlSerializable является полноценным типом и полиморфным, вы могли бы создать сериализатор документов, который ничего не знает о вашем исходном типе, принимая только, скажем, массив типов XmlSerializable.
Теперь представьте, что вы можете использовать этот сценарий для других целей, например, для создания миксина, который гарантирует, что каждый класс, который смешивает его, регистрирует каждый вызов метода, или миксина, который обеспечивает транзакционность для типа, который его смешивает. Список можно продолжать и продолжать.
Если вы просто думаете о миксине как о небольшом базовом типе, предназначенном для добавления небольшого количества функциональности к типу, без какого-либо влияния на этот тип, то вы просто великолепны.
Мое понимание соглашений, которые управляют чем-то, что вы бы назвали миксином, таково, что миксин:
Таким образом, он ограничивает потенциальную сложность множественного наследования и позволяет достаточно легко отслеживать поток вашей программы, ограничивая область поиска (по сравнению с полным множественным наследованием). Они похожи на рубиновые модули.
Если я хочу добавить переменные экземпляра (с большей гибкостью, чем допускается одиночным наследованием), я склоняюсь к компоновке.
Сказав это, я видел классы с именем XYZMixin, которые имеют переменные экземпляра.
Что отличает миксин от множественного наследования? Это просто вопрос семантики?
Пример множественного наследования
Этот пример, из документации, является OrderedCounter :
Это мощный способ повторного использования кода, но он также может быть проблематичным. Если окажется, что в одном из объектов есть ошибка, ее исправление может привести к ошибке в подклассе.
Пример миксина
Миксины обычно рекламируются как способ повторного использования кода без потенциальных проблем связывания, которые могут возникнуть при совместном множественном наследовании, как, например, OrderedCounter. Когда вы используете миксины, вы используете функциональность, которая не так тесно связана с данными.
В отличие от приведенного выше примера, миксин не предназначен для самостоятельного использования. Это обеспечивает новую или другую функциональность.
Например, в стандартной библиотеке есть несколько смесей в socketserver библиотека.
Версии Forking и Threading для каждого типа сервера могут быть созданы с помощью этих смешанных классов. Например, ThreadingUDPServer создается следующим образом:
Первым является смешанный класс, поскольку он переопределяет метод, определенный в UDPServer. Установка различных атрибутов также изменяет поведение базового серверного механизма.
Надуманный пример
И использование будет:
Я думаю, что здесь было несколько хороших объяснений, но я хотел представить другую точку зрения.
В Scala вы можете создавать миксины, как описано здесь, но что очень интересно, это то, что миксины фактически «слиты» вместе, чтобы создать новый тип класса для наследования. По сути, вы не наследуете от нескольких классов / миксинов, а генерируете новый тип классов со всеми свойствами миксина, от которых наследуются. Это имеет смысл, поскольку Scala основан на JVM, где множественное наследование в настоящее время не поддерживается (начиная с Java 8). Этот тип класса mixin, кстати, является специальным типом, называемым Trait в Scala.
Существуют способы заставить MRO с множественным наследованием работать в Python, в частности, функцию super (), но это означает, что вы должны выполнить всю иерархию классов, используя super (), и понять процесс управления значительно сложнее.
Возможно, пара примеров поможет.
Второй пример: инструментарий GUI wxPython позволяет создавать элементы управления списком с несколькими столбцами (как, например, отображение файла в проводнике Windows). По умолчанию эти списки являются довольно простыми. Вы можете добавить дополнительные функции, такие как возможность сортировки списка по определенному столбцу, щелкнув заголовок столбца, наследуя от ListCtrl и добавив соответствующие миксины.
Это не пример Python, но в языке программирования D используется термин mixin используется для ссылки на конструкцию, используемую почти таким же образом ; добавив кучу вещей в класс.
В D (который, кстати, не делает MI), это делается путем вставки шаблона (подумайте о синтаксически осведомленных и безопасных макросах, и вы будете близки) в область действия. Это позволяет использовать одну строку кода в классе, структуре, функции, модуле или любом другом объекте для расширения до любого количества объявлений.
Может быть, пример из ruby может помочь:
Это делается путем вызова (other) и возврата правильного результата.
Mixin дает возможность добавить функциональность в класс, т. е. вы можете взаимодействовать с методами, определенными в модуле, включив модуль в нужный класс. Хотя ruby не поддерживает множественное наследование, но предоставляет mixin как альтернативу для достижения этой цели.
Вот пример, который объясняет, как множественное наследование достигается с помощью mixin.
OP упомянул, что он / она никогда не слышал о mixin в C ++, возможно, это потому, что они называются Curily Recurring Template Pattern (CRTP) в C ++. Также @Ciro Santilli отметил, что mixin реализован через абстрактный базовый класс в C ++. В то время как абстрактный базовый класс может использоваться для реализации mixin, это является излишним, поскольку функциональность виртуальной функции во время выполнения может быть достигнута с использованием шаблона во время компиляции без накладных расходов на поиск виртуальной таблицы во время выполнения.
Шаблон CRTP подробно описан здесь.
Я преобразовал пример python в ответе @Ciro Santilli в C ++, используя шаблонный класс ниже:
РЕДАКТИРОВАТЬ: Добавлен защищенный конструктор в ComparableMixin, так что он может быть только унаследован и не создан. Обновлен пример, чтобы показать, как защищенный конструктор вызовет ошибку компиляции при создании объекта ComparableMixin.
Я просто использовал Python Mixin для реализации модульного тестирования Python Milters. Как правило, milter разговаривает с MTA, что затрудняет юнит-тестирование. Тестовый миксин переопределяет методы, которые общаются с MTA, и вместо этого создает моделируемую среду, управляемую тестовыми примерами.
Итак, вы берете немодифицированное приложение milter, такое как spfmilter, и mixin TestBase, например:
Затем используйте TestMilter в тестовых случаях для приложения milter: