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