То что вы сейчас делаете, огромный молодец, ВСЕ ИДЁТ НОРМАЛЬНО, ДАВАЙТЕ
МЫШЛЕНИЕ СДЕЛАЕМ ТОЧНЕЕ. УВЕЛИЧИМ ПОНИМАНИЕ АБСТРАКТНОГО
КЛАССА, ИНТЕРФЕЙСА, ТОГДА ЗАКОННЫЕ МЕСТА ЗАЙМУТ И ГЛАВНОЕ
ВПИШУТСЯ ЕСТЕСТВЕННЫМ ОБРАЗОМ И ДЕКОРАТОРЫ И МИКСИНЫ. Я ВИЖУ.
ЧТО КОД ВЫ ПИШЕТЕ ВСЕ УВЕРЕННЕЕ — ЭТО РАДУЕТ.
Сергей Осадчий молодчина.
Мне нужно пару дней, я переварю ваш код и сделаю по нему оснастку к урокам.
Цель этой статьи. Я хочу. Что бы вы начали использовать абстрактные классы и интерфейсы, а уже в дополнение к ним миксины и декораторы, так же не забываем про метод супер.
То что вы сейчас делаете, огромный молодец, ВСЕ ИДЁТ НОРМАЛЬНО,
ДАВАЙТЕ МЫШЛЕНИЕ СДЕЛАЕМ ТОЧНЕЕ. УВЕЛИЧИМ ПОНИМАНИЕ
АБСТРАКТНОГО КЛАССА, ИНТЕРФЕЙСА, ТОГДА ЗАКОННЫЕ МЕСТА ЗАЙМУТ И
ГЛАВНОЕ ВПИШУТСЯ ЕСТЕСТВЕННЫМ ОБРАЗОМ И ДЕКОРАТОРЫ И МИКСИНЫ. Я
ВИЖУ. ЧТО КОД ВЫ ПИШЕТЕ ВСЕ УВЕРЕННЕЕ — ЭТО РАДУЕТ.
Что сделано очень классно?
1. Вы молодчина, начали писать по частям. То есть сначала взяли блок адрес.
Так и далее работайте по блокам.
2. Так же в своём лексиконе вы начали использовать уже тондем
ваша фраза: - "классы, функции, миксины, декораторы для блока (адрес)."
то есть начала вырисовываться картина, что вы собираетесь использовать.
3. начали писать варианты. То есть начали понимать, что код можно реализовать по разному.
4. Спасибо огромное. что не забыли про метод super.
class Center(AddressMixin):
def __init__(self):
super(Center, self).__init__()
В данном коде явно видно, что class Center является родителем и вся работу будет идти в отношении этого класса.
Пожалуйста никогда не забывайте про метод super, так как, если не применять этот метод, то жизнь сильно усложнится.
Над чем нужно ещё работать.
1. Нужно продолжить работу над целями применения миксинов и декораторов, так как пока уверенного
понимания нет. Радует, что понимание более глубокое, но пока немного плаваем.
Значит пока пишем и пишем код.
Что нужно уже сейчас поправить в понимании?
1. Смотрите, вы миксин наделили полными полномочиями реализации самого блока адрес.
Попытка наделить полномочиями класс Center все же была вот здесь
class Center(AddressMixin):
def __init__(self):
super(Center, self).__init__()
Теперь давайте разбираться.
Миксин - переводится, как примесь.
То есть сама логика должна быть реализована уже и при помощи миксина/ов мы привносим в программу точные действия.
Вдумайтесь в смысл, миксин привносит некое точно действие, не изменяя самого класса, не изменяя кода.
А декоратор изменяет поведение функции/метода.
Сергей, спорить я не буду с вами, потому что я вам сам показывал фреймворки, которые реализованы на декораторах.
Но все же вижу. что нет у вас в голове точного понятия, когда и где все-таки применять ДЕКОРАТОРЫ и миксины.
Что необходимо добавить сейчас?
Что бы стало все на места, необходимо ввести абстрактный класс и описать основные блоки и их логику, как абстрактные классы, тогда миксины и декораторы
займут своё естественное место.
алгоритм:
Основная логика абстрактный класс или интерфейс.
Например, мы реализуем блок адрес. как абстрактный класс или, как интерфейс. пока у нас тут тоже вопрос подвис,
а хотелось бы увидеть в коде в каком случае применять просто абстрактный класс, а в каких интерфейс.
Потом мы реализуем блок персонал.
А потом написав миксин, который мы может добавить и в класс Adress и в класс Personnel, ну например добавить доступ к редактированию сотрудников.
То есть мы пишем миксин, принадлежности к группе например.
И добавив этот мискин
в класс Adress и в класс Personnel, мы достигаем, что редактировать могут только люди имеющие отношение к этой группе.
Тогда миксин становится на своё место и его роль выполняется, как задумано.
На миксин можно возлагать и более широкие вещи, добавление кусков логики, но не нужно отходить от цели миксина, ЧТО ОН ДОБАВЛЯЕТ ТОЧНОЕ ДЕЙСТВИЕ.
И ТАК ЖЕ НЕ ЗАБЫВАТЬ, ЧТО МИКСИН НЕ МОЖЕТ СУЩЕСТВОВАТЬ БЕЗ КЛАССА САМ ПО СЕБЕ, ИНАЧЕ ЭТО УЖЕ НЕ МИКСИН, А ПРОСТО КЛАСС.
Вывод:
Реализуйте основную логику класса Adress, как абстрактный класс один вариант.
Второй вариант, как интерфейс, тогда увидите разницу.
Небольшая справка для напоминания.
Абстрактный класс требует реализации, хотя бы одного метода. Интерфейс это тот же абстрактный класс, но не требующий конкретной реализации
метода.
Дело интерфейса это проверка и порядок.
пример 1. Цех в котором находятся разные предметы станки, рабочие в спец одежде, канц. товары.
Все эти предметы относятся к разным категориям.
И могу хранится в разных местах до выдачи в цех и проходить по разным книгам учёта.
Например. если бы мы описывали склад, то там мы бы могли смело применить абстрактный класс, так как мы точно знаем. что это склад со станками.
Но если это цех, то здесь абстрактный класс будет немного не уместен, ведь цеха разные по комплектации.
В одном цехе будут как я описал станки, канц товары и спец.одежда.
А в другом будут ванны, краски и оборудование и спец. одежда.
Когда комплектация разная, нам важнее проверить, что все есть и где и что расположено.
Так написав интерфейс, мы легко можем сформировать объекты, которые состоят из разных частей.
То есть интерфейс, проверит, что покрасочный цех имеет краску, краскопульты, спец одежду.
Он ничего не будет знать, сколько краски, его задача проверить что в этом цехе краска.
А вот в дочерних классах мы можем реализовать методы или свойства этих объектов, то есть разделить краски на цвета, на количество литров.
То же объяснение но под другим углом зрения.
Что бы точнее понять, что для чего использовать нужно понять, для чего были придуманы.
Абстрактный класс мы даже рассматривать не будем, так как здесь все итак предельно прозрачно.
Из определения, абстрактный класс требует реализации хотя бы одного метода.
То есть применяем мы его, когда ситуация однозначна и требются одни и те же действия, а точнее сказать, когда поведение
нам точно известно и оно шаблонно.
Например, абстрактный класс Джанго по добавлению полей.
Мы создаём абстрактный класс, куда добавляем какие то общие поля, дата, создание, обновление, название.
мы создаем абстрактный класс с полями и потом при создании дочерних классов, в каждый дочерний класс будут добавлены поля с абстрактного класса. Удобно, мало кода. Высокая доступность к коду в пределах одних и тех же классов, можно реализовать совершенно разные вещи динамически. Роль абстрактного класса в этом случае, что в дочерних классах, мы реализуем совершенно разные задачи. Которые не пересекаются, например в одни поля добавляем только цифры. В другие картинки, в третьих что то подсчитываем, это даёт нам коммуникабельность, то есть мы можем потом размещать поля в разных частях контента делать это просто и главное оперировать можем легко и компоновать. Как хотим и главное всегда есть возможность дописать что-то новое.
То есть как мы видим действия везде шаблонны и при этом очень точны, так как методы требуют именно создания полей, ничего другого нельзя делать, только поля. А вот сами поля могут быть сколь угодно разными.
На выходе, как это работает.
Поля могут быть созданы только как описано в методе. В джанго этот так:
created = models.DateTimeField(auto_now_add=True)
то есть сам порядок
название = класс по созданию полей модели… само поле(свойства поля)
Из примера видно, что есть чёткий шаблон, как и что делать.
Ну зачем же тогда люди придумали интерфейсы?
А интерфейс, не требует выполнения какого-то метода, то есть нет никаких точных действий.
Интерфейс проверяет порядок и наличие.
Но интерфейс не проверяет саму реализацию, как это я показал выше в примере с джанго.
Когда это используется. В жизни мы используем интерфейсы каждодневно.
Вы едите с дома на смоленский рынок за мясом.
Вы решили ещё дома точно, я поеду на рынок на троллейбусе № 7. То есть сейчас ваш мозг реализует абстрактный класс. В котором есть.
Что купить и где. (мясо на смоленском рынке)
маршрут (ваш дом — смоленский рынок)
вид транспорта и номер (троллейбус № 7)
То есть ваш мозг если это выразить в коде псевдокласса:
псевдокод код, когда мы пишем не код, а осмысленные задачи из осмысленных предложений, так легко думать.
Домашнее задание 1.
Ситуацию можно взять свою. Важно в домашнем задании должно быть понятно что деалет абстрактный класс основная логика и метод/ы, которые реализуются.
И дальше привносим изменения при помощи декораторов и миксинов.
class purchases():
Сами распишите методы словами. Но расписать нужно так, что бы был сам метод, а вот составляющие вы могли поменять, то есть другой раз мы могли бы поехать на автобусе за велосипедом и по другому маршруту, но все равно ваши действия всегда будут укладываться в основной шаблон.
Если мы хотим внести некие изменения а нашу схему мы тогда и применяем декораторы, приехали на рынок, мяса не было или было нето, и вы купили картошки. Что бы не ехать домой пустым (это декоратор)
Или мы хотим внести дополнительные точные действия, например жена вам сказала, покупай на рынке в роллете 7, 12, 23 в других не покупай там дорого или что то не то. Это уже миксин, то есть само действие покупки есть, но при помощи миксина мы уточняем со всего рынка покупать только в трёх местах.
Вот и вы напишите пока псевдо код, но дополните свой код декоратором и миксином.
Сергей заметьте в данном примере все соотвествует нашему нормальному мышлению.
Абстрактный класс – порядок действия основной.
Вывод по жизни. Мы мужчины в большинстве своём не любим тоскаться по магазинам, поэтому мыслим асбтактными классами, поехал купил - приехал. Нам нужная ясность, наименьшие затраты времени и желательно качество.
Интерфейсы.
Но вот женщина мыслит по иному в каждодневном своём мышлении, женщина мыслит интерфейсами. Так как у неё больше составляющих в голове в один и тот же момент времени. Забота о семье, забота о бюджете, качество и цена, женщина от природы заслуживает большего уважения чем мы ей отдаём его, так как именно женщины разменивают время свой жизни ради нас.
Рассмотрим знакомую ситуацию.
Жена собирается за мясом.
В её наборе будут другие методы, которые не требуют реализации в каком то определённом порядке, то есть она будет мыслить в данном случае интерфейсами.
ТО есть это тот же абстраткный класс, но у которого есть только освовные части и они не требуют реализации никакой вообще.
Давайте рассмотрим интерфейс.
Домашнее задание 2.
Распишите интерфейс, согласно объяснения ниже, ситуация может быть иной, важно, что бы никакие методы не реализовывались точно, а проверялся только порядок и наличие.
class ShoppingWoman():
ваш псевдокод.
Наша вторая половина когда выходит из дома, например за мясом, да она говорит еду за мясом нам, а в голове у ней более глобальные вещи это будет метод продукты.
Да при разговоре она говорит еду за мясом, но ведь в её голове есть понятия, меню, что мужу купить нужно, что себе.
То есть первый метод продукты.
Второй метод двигаться. Ведь дома если сидеть, то продуктов не купишь. (мы сейчас опусти онлайн покупки, хотя это тоже одно из действий).
Маршрут.
Иными словами её класс в голове выглядит так:
the products (продукты) – None (пока ничего)
route (маршрут) - None (пока ничего)
movement (передвижение) - None (пока ничего)
То есть ей чётко понятно, что она собирается идти или ехать за продуктами по маршруту, который построит на ходу.
В данном случае мы видим интерфейс. Где есть что делать. То есть пойти за покупками, в зависимости от купленного и цены выбрать маршрут и там уже по ситуации смотреть идти пешком, ехать или вообще прийти домой и заказать онлайн.
То есть интерфейс проверяет только наличие основных компонетнтов и может проверять порядок. (порядок должен проверяться например в парикмахерской, например сначала волосы моются. А потом красяться, но никак не наоборот).
Вернёмся к нашей хозяйке. Она выходит их дома за продуктами. Но где будет покупать не определно. Так как задёт например в Петруху магазин посмотрит цены, потом поедет на рынок, но здесь звонит Нинка, которая говорит, что она на шашлыках и мясо они купили в новом магазине и там большие скидки, а ещё там открылся новый магазин косметики и там недорого и хороший выбор. В данном случае она могла быть в магазине Петруха и уже собиралась ехать на маршрутке, но после вводной из разговора, принимает решение ехать на автобусе и в другую сторону, а там рядом рынок, зайти ещё и туда и купить мужу станок (была рядом. Чего не купить, тем более была скидка).
Когда приехела домой. Все довольны. Семья довольна мясо о котором говорили с утра, есть, жена довольна купила себя новую тушь и муж доволен ему купили новое лезвие, а то старое уже плохо брило.
В данном случае мы увидели работу интерфейса, где закладывались только сами методы, продукты, двигаться куда-то и маршрут. Но эти методы не требовали реализации точной.
НЕ было определено, движение на каком именно транспорте, да в голове держалось купить мясо, но опять же, где купить зависело от ситуации (цены, звонка), от этого и потом строился маршрут и выбор транспорта.
Как вы увидели интерфейс мы применяем, тогда, когда есть чёкое понимание что сделать, но каким образом это сделать не представялется возможным описать, из за много ходовости, то есть мы описываем это позже, но уже исходя из разных ситуаций.
Я вам показал, что в жизни и асбрактные классы и интерфейсы мы применяем ежедневно..
Но в описанной ситуации с хозяйкой, она так же применяет декораторы и миксины ежедневно. Ну например, была в том магазине. Где мясо хорошее, но рядом рынок. Хозяка додвляет миксин, посещая магазин, посетить и рынок, потму что он рядом. Или если мяса не было, то купить фарш (декоратор).
Интерфейсы полностью соотвествуют нашей жизни и были взяты из жизни. Когда понятно что сделать, но как сделать не определено, так как много воодных.
Они очень удобны, интерфейсы проверяют наличие и порядок, но как это будет реализовано об этом интерфейсы ничего оне знают.
Благодаря этому получили реализацию сложные игры компьютерные и так же можно описывать любые сложные вещи. Просто чуть похже мы изучи виды абсракций (взаимодействие и изменение свойств в методах)
Наша задача состоит в том. Что бы точно определить где использовать интерфейс. А где просто абстрактный класс.
Домашнее задание 2. часть 2.
Следующую неделю понаблюдайте за своими знакомыми или родными и постарайтесь потом описать день, поездку. Куда либо, сначала. Как псевдокод и написать, как бы вы описали её действия (матери, сестры, жены, подруги,друга и т .д ). Как абстрактный класс или интерфейс, что бы записали в декораторы, что бы в миксины. Очень важно понимать это легко, тогда любое техническое задание будет вами легко читаться и вы сразу будете видкть реализацию. Потому что пока вы язык отрываете от жизни он и будет набором команд не понятных вам. Как только в жизни вы начинаете видеть ООП, то вам остаётся только решить вопрос. А как это можно выразить технически, так как вы дано для себя решили теоретически, что в каких-либо действиях вы бы описали, как основную логику, какие бы добавления внесли при помощи миксинов и где бы хотели, что-то изменит при помощи декораторов.
Домашнее задание 3.
Сергей прочитав этту статью. Я вас прошу переписать ваш класс адрес в таком порядке.
Вариант 1.
Описать класс Адрес, как абсраткный класс, добавить метод супер и определить мксины и декораторы, с чётким пояснением что и почему вы реализовали, как основной алгоритм, что реализовали, как декторатор, что как миксин.
Вариант 2.
Описать класс Адрес, как интерфейс, добавить метод супер и определить миксины и декораторы, с чётким пояснением что и почему вы реализовали, как основной алгоритм, что реализовали, как декоратор, что как миксин.
Я рекомендую сначала описать псевдокод. То есть то что вы хотите прописать словами. А потом реализовать в коде.