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