Огонь, весьма простая и интересная альтернатива грозди декораторов) а на счёт совмещения функций и дандеров - прям кайфанул) (пришло в голову - замутить декоратор с применением данного паттерна)
Изначально была проблема в том, что мы мутируем входные параметры и, в какой-то момент, забываем, что тут происходит, и в каком порядке все это делать. Решение: перепишем все на классы, чтобы спрятать всю эту "красоту" с глаз подальше. Великолепный план, Уолтер, просто охуенный, если я правильно понял.
Ну тогда выкиньте миддлвари из веб фреймворков и вообще лучше идите в функциональный мир где такого не бывает. Мир не идеален - селяви) Имхо, но тут больше речь про организацию кода, когда у тебя не по две строчки в ифах (как в примере), а полотно в каждом из них, такой код тяжело читать. Вот вам и идея как разбить эти блоки на классы, сделать из каши какойто алгоритм и при этом каждый из этих классов ещё и своим названием может помогать понять за что он отвечает.
@@sihnelsi1623 ну в питоне было бы логичнее наверное создать класс handlers и в него разместить все эти handler'ы в виде статических методов, таким образом код будет более читаемым (есть отдельный неразрывный блок кода, в котором записаны все обработчики, при том они все имеют понятные, говорящие сами за себя названия)
Очень важный упущенный момент в данном видео - то что чистые функции без зависимостей редко бывают полезны. То есть еще нужно было бы рассказать что конструктор например может принять некий аргумент с зависимостью (сервисом например или конфигом) и использовать эти зависимости в чейне. Аналогично с функцией и замыканиями, когда в main мы можем передать в функцию высшего порядка аргументы, а результатом этой функции будет - handler сконфигурированный и проинициализированный.
Заумный способо сделать )) ``` def handle_data(data, handlers): for handler in handlers(): data = handler(data) return data data = handle_data(data, login_handlers) ```
Если изменение порядка ифов приводит к "и вот вы уже сами не знаете что с этим делать и как это работает", то мне кажется стоит подумать о карьере в Яндексе (курьером).
Не знал, что вынос проверок в отдельные абстракции с единым API для вызова в цикле -- это какой-то важный паттерн с англыцким названием. В любом случае, это более актуально для запутанных случаев, когда Вы "по быстрому" добавляли в существующие if`ы всё новые And и Or, а через месяц-другой обнаружили, что приложение неправильно обрабатывает одну ситуацию =)) И ещё такой момент. Вызывать в цикле 10 хэндлеров для обработки авторизованного пользователя, когда на сайт зашёл неавторизованный -- это оверхэд на 10 лишних вызовов и 10 лишних проверок. В этом смысле, "вложенное" и "иерархическое" может работать сильно быстрее "плоского" и "эгалитарного".
Ну, так всегда бывает, когда best practicies для очень сложных проектов берут и применяют к очень простым задачам. Так, что даже простой скриптик из 20 строчек можно превратить в целый Python пакет из дюжины слоёв и сотни классов по лучшим заветам Domain Driven Design и Clean Architecture, но зато без этих "ужасных глобальных переменных" =))
Если бы я не прочитал, что это просто по сути своей "цепочка", то я бы не въехал в объяснение этого метода. Думаю, сначала надо пояснить нафига этот пАттерн вообще нужен на упрощенной схеме (та же проверка пользователей на сайте, где происходит аутентификация, затем авторизация и т.д.). По такому примеру, который на коленке расписан - непонятна суть паттерна(ИМХО)
А чего в этом плохого? Эфемерный python-way, это не догма и не грааль. Все имеет свои области применимости. Чуваки из жаба-мира пишут кровавый энтерпрайз уже много лет и хорошие вещи можно и нужно перетаскивать к себе в питон. Особенно когда сам пишешь нормальный промышленный код, а не прототип на коленке из говна и палок)
Огонь, весьма простая и интересная альтернатива грозди декораторов) а на счёт совмещения функций и дандеров - прям кайфанул) (пришло в голову - замутить декоратор с применением данного паттерна)
Изначально была проблема в том, что мы мутируем входные параметры и, в какой-то момент, забываем, что тут происходит, и в каком порядке все это делать. Решение: перепишем все на классы, чтобы спрятать всю эту "красоту" с глаз подальше. Великолепный план, Уолтер, просто охуенный, если я правильно понял.
Ну тогда выкиньте миддлвари из веб фреймворков и вообще лучше идите в функциональный мир где такого не бывает. Мир не идеален - селяви)
Имхо, но тут больше речь про организацию кода, когда у тебя не по две строчки в ифах (как в примере), а полотно в каждом из них, такой код тяжело читать. Вот вам и идея как разбить эти блоки на классы, сделать из каши какойто алгоритм и при этом каждый из этих классов ещё и своим названием может помогать понять за что он отвечает.
Ну если у тебя в функции 5 строк, то зачем тебе вообще юзать ооп
@@sihnelsi1623 ну в питоне было бы логичнее наверное создать класс handlers и в него разместить все эти handler'ы в виде статических методов, таким образом код будет более читаемым (есть отдельный неразрывный блок кода, в котором записаны все обработчики, при том они все имеют понятные, говорящие сами за себя названия)
Ну а с этим кодом, первое что в голову приходит - можно посмотреть список наследников от Handler, и опять же узнать полный список условий
Очень важный упущенный момент в данном видео - то что чистые функции без зависимостей редко бывают полезны. То есть еще нужно было бы рассказать что конструктор например может принять некий аргумент с зависимостью (сервисом например или конфигом) и использовать эти зависимости в чейне. Аналогично с функцией и замыканиями, когда в main мы можем передать в функцию высшего порядка аргументы, а результатом этой функции будет - handler сконфигурированный и проинициализированный.
Заумный способо сделать ))
```
def handle_data(data, handlers):
for handler in handlers():
data = handler(data)
return data
data = handle_data(data, login_handlers)
```
Если изменение порядка ифов приводит к "и вот вы уже сами не знаете что с этим делать и как это работает", то мне кажется стоит подумать о карьере в Яндексе (курьером).
Не знал, что вынос проверок в отдельные абстракции с единым API для вызова в цикле -- это какой-то важный паттерн с англыцким названием. В любом случае, это более актуально для запутанных случаев, когда Вы "по быстрому" добавляли в существующие if`ы всё новые And и Or, а через месяц-другой обнаружили, что приложение неправильно обрабатывает одну ситуацию =))
И ещё такой момент. Вызывать в цикле 10 хэндлеров для обработки авторизованного пользователя, когда на сайт зашёл неавторизованный -- это оверхэд на 10 лишних вызовов и 10 лишних проверок. В этом смысле, "вложенное" и "иерархическое" может работать сильно быстрее "плоского" и "эгалитарного".
... и получаем охуено запутанный и неподдерживаемый код
Ну, так всегда бывает, когда best practicies для очень сложных проектов берут и применяют к очень простым задачам. Так, что даже простой скриптик из 20 строчек можно превратить в целый Python пакет из дюжины слоёв и сотни классов по лучшим заветам Domain Driven Design и Clean Architecture, но зато без этих "ужасных глобальных переменных" =))
Если бы я не прочитал, что это просто по сути своей "цепочка", то я бы не въехал в объяснение этого метода. Думаю, сначала надо пояснить нафига этот пАттерн вообще нужен на упрощенной схеме (та же проверка пользователей на сайте, где происходит аутентификация, затем авторизация и т.д.). По такому примеру, который на коленке расписан - непонятна суть паттерна(ИМХО)
На первый взгляд это не очень python-way, скорее похоже на java-way, особенно с абстрактными классами классов)
Но материал любопытный, подписался)
А чего в этом плохого? Эфемерный python-way, это не догма и не грааль. Все имеет свои области применимости. Чуваки из жаба-мира пишут кровавый энтерпрайз уже много лет и хорошие вещи можно и нужно перетаскивать к себе в питон.
Особенно когда сам пишешь нормальный промышленный код, а не прототип на коленке из говна и палок)
Объяснение хорошее, но пример не удачный. В данном случае это скорее антипаттерн