Я вообще один раз предпочёл закончить интервью на моменте когда у меня спрашивали контакты бывших коллег и начальства. Я же не продукт, чтобы ходили собирали отзывы обо мне. Да и вообще почему моё трудоустройство должно зависить от людей с которым я должен был работать? А если человек на меня зуб заточил? То что он скажет ценнее чем то что я сам могу о себе рассказать?
способ попробовать понять свою аудиторию до запусков и даже до настоящих глубоких исследований рынка.
Я уже невпервой вижу исследования ПОЛЬЗОВАТЕЛЬСКОГО ОПЫТА через ИИ, у которого его не может быть по определению. Сначала я думал что мне показалось, но эта статья говорит что нет.
Скажите, с точки зрения актуальности информации, вообще на сколько она близка к реальности?)) Или все это устанавливается и делается чтобы показать начальнику что-то? Как можно вообще на это опираться на этапе когда ты думаешь нужен продукт рынку или нет?
Либо я имею объект пользователя на всё приложение и например модуль авторизации которым могу в каждом эндпоинте проверять все что захочу у пользователя. Вообщем декорирование это синтаксический сахар, он и правда может использоваться где угодно, как собственно и не использоваться.
Можете не копать, области видимости питона принципиально ни чем не отличаются от области видимости в других языках. Построение области видимости на декораторах это вообще что-то новое и возможно даже невероятное.
Никаких противопоказаний, а польза то какая? Так и не могу услышать. Я уверен, что смогу и без декораторов написать на питоне прекрасную авторизацию через ООП, а вы говорите что им самое место в авторизации, почему?
И потому что, он полезен тем, что внутри декоратора есть свои уровни пространств имен, доступ к которым есть во вложенных в декоратор функциях, но это в любом случае свойство функций и сам синтаксический сахар тут не причем
Как-то вы обошли пользу пространства имён декораторов в статье.
На самом деле, область применения декораторов ограничивается лишь фантазией и некоторыми нюансами языка в целом и его синтаксиса, однако, целесообразность, на мой взгляд, важнее возможности использовать тот или иной паттерн.
И дальше вы выделяете именно авторизацию как успешный пример декораттра.
Дак он чаще используется там, именно на питоне, хочу подчеркнуть, потомучто это удобный синтаксический сахар встроенный в язык? Или потомучто он помогает как-то в хэшировании, логировании, авторизации и еще куче полезных бизнес мест? Я так предполагаю что декораторы вообще можно в любом месте библиотеки встретить, потомучто это синтаксичкский сахар и никакого отношения к конкретному функционалу не имеет.
Тогда декоратор имеет место быть где угодно, не только в авторизации, зачем вообще этот список полезных мест?
Вы, по сути, можете реализовать декоратор, не только в питоне, он там идёт из коробки, но в других языках как-то обходятся без декоратора в авторизации, например. Или только в питоне такая особенность авторизации?)
Приведу некоторые примеры когда применение декораторов имеет смысл списком, чтобы не было необходимости проваливаться в статьи:
Оптимизация производительности функций (кэширование);
Тайминг и профилирование (измерение времени выполнения функции, проверки производительности);
Авторизация и аутентификация (проверки по типу login_required);
Вот, вы именно это и говорите. Привели в пример потомучто есть в библиотеке? И статья называется продвинутое использование декораторов. В чем их продвижение то?
Либо не использовать декораторы вообще. Я просто маленько упустил, погружаясь в материал, как мы ушли от "Декораторы отлично себя показывают в аторизации" к "Ну декораторы вот используется в библиотеках другими программистами" По ссылкам я просто вижу что они вызываются, что это должно сказать?)
Декоратор в большей мере необходим для удобства использования какого-то фрагмента кода
А наследование?
Вообще, я считаю, что в хорошей архитектуре ООП 70% кода пишется путем копировать - вставить, что-бы соблюсти архитектурный паттерн. И достигается это не наследованием, а интерфейсами.
Под более объемной логикой я имел в виду, что используя классы мне по-хорошему нужно будет описать интерфейсы, возможно описать какие-то базовые классы, описать реализации. А написав функцию я просто ее напишу в одном месте.
Вы имеете ввиду что просто вообще весь код постараетесь уместить в 1 функцию?
Почитал пример декоратора с классами, вы приводите по сути реализацию гетера и сеттера на декораторах, он, если меня память не подводит, в С# вообще по умолчанию прописывается. Я к тому что декоратор в классах тоже выглядит лишним или избыточным.
Декоратор вместо класса? Или декоратор вместо всей логики авторизации/аутентификации? И как понять более объемную логику? Вам в (или на декораторах, тут непонятно, если вы говорите что вложенные декораторы это плохо) декораторе точно так-же придется делать аутентификацию на какой-то реализации куки. Но по моему изначально класс под это намного лучше подходит в плане построения логики? Темболее в питоне есть прекраные магические методы, которые, получается, как декораторы, но над объектами.
Я вообще один раз предпочёл закончить интервью на моменте когда у меня спрашивали контакты бывших коллег и начальства. Я же не продукт, чтобы ходили собирали отзывы обо мне. Да и вообще почему моё трудоустройство должно зависить от людей с которым я должен был работать? А если человек на меня зуб заточил? То что он скажет ценнее чем то что я сам могу о себе рассказать?
Вы сами говорите что бизнесу не надо именно вас нанять, а когда кто-то порекомендовал, бизнесу сразу нужны именно вы?)
А почему рекомендацию не могут отбросить если человек, опять же, не писал на нужном фреймворке?
Я уже невпервой вижу исследования ПОЛЬЗОВАТЕЛЬСКОГО ОПЫТА через ИИ, у которого его не может быть по определению. Сначала я думал что мне показалось, но эта статья говорит что нет.
Скажите, с точки зрения актуальности информации, вообще на сколько она близка к реальности?)) Или все это устанавливается и делается чтобы показать начальнику что-то? Как можно вообще на это опираться на этапе когда ты думаешь нужен продукт рынку или нет?
Ищите кто сможет реализовать кэширование кода на декораторах?))
Либо я имею объект пользователя на всё приложение и например модуль авторизации которым могу в каждом эндпоинте проверять все что захочу у пользователя. Вообщем декорирование это синтаксический сахар, он и правда может использоваться где угодно, как собственно и не использоваться.
Можете не копать, области видимости питона принципиально ни чем не отличаются от области видимости в других языках. Построение области видимости на декораторах это вообще что-то новое и возможно даже невероятное.
Никаких противопоказаний, а польза то какая? Так и не могу услышать. Я уверен, что смогу и без декораторов написать на питоне прекрасную авторизацию через ООП, а вы говорите что им самое место в авторизации, почему?
Как-то вы обошли пользу пространства имён декораторов в статье.
И дальше вы выделяете именно авторизацию как успешный пример декораттра.
Дак он чаще используется там, именно на питоне, хочу подчеркнуть, потомучто это удобный синтаксический сахар встроенный в язык? Или потомучто он помогает как-то в хэшировании, логировании, авторизации и еще куче полезных бизнес мест? Я так предполагаю что декораторы вообще можно в любом месте библиотеки встретить, потомучто это синтаксичкский сахар и никакого отношения к конкретному функционалу не имеет.
Тогда декоратор имеет место быть где угодно, не только в авторизации, зачем вообще этот список полезных мест?
Вы, по сути, можете реализовать декоратор, не только в питоне, он там идёт из коробки, но в других языках как-то обходятся без декоратора в авторизации, например. Или только в питоне такая особенность авторизации?)
Вот, вы именно это и говорите. Привели в пример потомучто есть в библиотеке? И статья называется продвинутое использование декораторов. В чем их продвижение то?
Либо не использовать декораторы вообще. Я просто маленько упустил, погружаясь в материал, как мы ушли от "Декораторы отлично себя показывают в аторизации" к "Ну декораторы вот используется в библиотеках другими программистами" По ссылкам я просто вижу что они вызываются, что это должно сказать?)
А наследование?
Вообще, я считаю, что в хорошей архитектуре ООП 70% кода пишется путем копировать - вставить, что-бы соблюсти архитектурный паттерн. И достигается это не наследованием, а интерфейсами.
Вы имеете ввиду что просто вообще весь код постараетесь уместить в 1 функцию?
Извините меня конечно, ничего личного, но судя по вашей последней статье, я больше вижу подтверждение своему видению происходящего)
Почитал пример декоратора с классами, вы приводите по сути реализацию гетера и сеттера на декораторах, он, если меня память не подводит, в С# вообще по умолчанию прописывается. Я к тому что декоратор в классах тоже выглядит лишним или избыточным.
Декоратор вместо класса? Или декоратор вместо всей логики авторизации/аутентификации? И как понять более объемную логику? Вам в (или на декораторах, тут непонятно, если вы говорите что вложенные декораторы это плохо) декораторе точно так-же придется делать аутентификацию на какой-то реализации куки. Но по моему изначально класс под это намного лучше подходит в плане построения логики? Темболее в питоне есть прекраные магические методы, которые, получается, как декораторы, но над объектами.
Извините конечно меня, но с чего вы тогда взяли что это отличное место для декораторов? Ну и возможно еще чего-то из списка.