"от нее бы отказались в принципе" - и от нее оказались в Go, Rust...
"управления повторным использованием кода" можно делать с помощью композиции. Я не говорю, что наследованием не надо пользоваться, если оно есть в языке, но в большинстве случаев его стоит избегать в пользу композиции в продуктовом коде, хотя в каких-то суровых библиотеках оно вполне допустимо в разумных пределах
по п.2
если вы используете протоколы и проверку типов, то вам прийдется написать соотвествующий метод. Где надо вы явно вызовите валидатор, а не будете полагаться на неявную реализацию и цепочку переопределения методов в иерархии наследованная. Явное лучше не явного. И EmailNotification вы просто его не вызовете или используете NoOps валидатор и будет понятно, что тут проверка не делается
по п.1
"абстрактные классы необходимы, когда нужно передать общую реализацию или состояние", но еще лучше композиция, разделение ответственности и отсутствие состояния. Есть валидаторы, которые только валидируют, есть сендеры, которые только посылают сообщения, есть условный мессендж процессор, которому в рамках композиции передается валидатор и сендер, а он их дергает по очереди, и не нужны никакие абстрактные классы и состояние. И уж тем более не нужны абстрактные классы в маленьких сервисах - это инструмент для больших библиотек
Не вижу смысла в статье - есть документация. ИМХО это вкусовщина. Если глянуть на другие языки, то init гораздо больше похож на конструктор (нет явного возвращаемого значение и есть this/self), но функционал создания объектов размазан в питоне по куче методов и не только по этим двум
После появления протоколов, я полностью отказался от абстрактных классов в Питоне - по-моему утиная типизация (сердце Питона) гораздо лучше ложится на протоколы
Кажется вы решаете не существующую проблему страшно сложными методами. Гораздо проще определить валидаторы отдельно и дергать их напрямую в нужных местах, а не продираться сквозь нижележащий слои абстракции, нарушая инкапсуляцию
Ну и следствие этого. Вообще наследованное самая бесполезная штука в ООП а-ля Джава - ее не было у Алана Кэя и во многих более современных языках от нее успешно отказались. Собственно ваш пример показывает почему это частенько вредная штука
Если в счастье насильно загонять не будут, то никак шансов нет. Это абсолютно вторичный продукт от организации, у которой нет ресурсов конкурировать с передовыми решениями
Да и прикладные возвращают. Я вот пишу сейчас код для ClickHouse. Там интерфейс возвращается при создании клиента. Создателям языка задавали про это вопрос и они сказали, что нет такого правила возвращать структуру
Ну вроде в отличие от дженериков этот вопрос закрыли наконец. Я бы лично больше на монады result/optional согласился. ИМХО исключения это не очень хорошая концепция
Попробуйте чего-нибудь связанное с математикой и тренировкой сетей сделать, и сразу что-нибудь еще потребуется. Go неплох для перекладывания json, все остальное не про Go
А где вам часто требуется index, чтобы так по этому поводу переживать? Много писал на питоне, но чего-то не припомню, что хоть раз в реальном коде использовал. Без наезда, реально интересно
Я не силен в C, но кажется современные компиляторы должны вполне успешно это оптимизировать, особенно если переменная помечена явным способом, как константа
А думаете нет? У меня все в семье играют, кроме меня. Даже престарелые родители
Это около 100р в месяц - не какие-то огромные деньги
по п.3
"от нее бы отказались в принципе" - и от нее оказались в Go, Rust...
"управления повторным использованием кода" можно делать с помощью композиции. Я не говорю, что наследованием не надо пользоваться, если оно есть в языке, но в большинстве случаев его стоит избегать в пользу композиции в продуктовом коде, хотя в каких-то суровых библиотеках оно вполне допустимо в разумных пределах
по п.2
если вы используете протоколы и проверку типов, то вам прийдется написать соотвествующий метод. Где надо вы явно вызовите валидатор, а не будете полагаться на неявную реализацию и цепочку переопределения методов в иерархии наследованная. Явное лучше не явного. И EmailNotification вы просто его не вызовете или используете NoOps валидатор и будет понятно, что тут проверка не делается
по п.1
"абстрактные классы необходимы, когда нужно передать общую реализацию или состояние", но еще лучше композиция, разделение ответственности и отсутствие состояния. Есть валидаторы, которые только валидируют, есть сендеры, которые только посылают сообщения, есть условный мессендж процессор, которому в рамках композиции передается валидатор и сендер, а он их дергает по очереди, и не нужны никакие абстрактные классы и состояние. И уж тем более не нужны абстрактные классы в маленьких сервисах - это инструмент для больших библиотек
Но это все ИМХО - на вкус и цвет товарищей нет
Еще раз посмотрите на С++, Java, C#, где понятие конструктора явно существует и что он делает
Не вижу смысла в статье - есть документация. ИМХО это вкусовщина. Если глянуть на другие языки, то init гораздо больше похож на конструктор (нет явного возвращаемого значение и есть this/self), но функционал создания объектов размазан в питоне по куче методов и не только по этим двум
После появления протоколов, я полностью отказался от абстрактных классов в Питоне - по-моему утиная типизация (сердце Питона) гораздо лучше ложится на протоколы
Кажется вы решаете не существующую проблему страшно сложными методами. Гораздо проще определить валидаторы отдельно и дергать их напрямую в нужных местах, а не продираться сквозь нижележащий слои абстракции, нарушая инкапсуляцию
Ну и следствие этого. Вообще наследованное самая бесполезная штука в ООП а-ля Джава - ее не было у Алана Кэя и во многих более современных языках от нее успешно отказались. Собственно ваш пример показывает почему это частенько вредная штука
А как надо назвать?
Он помер, так и не выиграв, но секта фракталов живет
Которая всех послала на три буквы в 2022 году
Человек, который назвал сам себя сеньором, искал работу почти с удвоенной зп и не нашел. Можно еще с 10x поискать
Если в счастье насильно загонять не будут, то никак шансов нет. Это абсолютно вторичный продукт от организации, у которой нет ресурсов конкурировать с передовыми решениями
Да и прикладные возвращают. Я вот пишу сейчас код для ClickHouse. Там интерфейс возвращается при создании клиента. Создателям языка задавали про это вопрос и они сказали, что нет такого правила возвращать структуру
Это не так - вы наверняка в каждой второй функции возвращаете интерфейс ошибка
Частая схема - у вас ломают доступ в банк, который вы давно не используете. Вас убеждают туда перевести, а потом выводят с него средства
Duolingo редкостная хрень про которую давно открыто известно, что они не учат, а пытаются тебя максимально долго на деньги разводить
Ну вроде в отличие от дженериков этот вопрос закрыли наконец. Я бы лично больше на монады result/optional согласился. ИМХО исключения это не очень хорошая концепция
И слава богу
Попробуйте чего-нибудь связанное с математикой и тренировкой сетей сделать, и сразу что-нибудь еще потребуется. Go неплох для перекладывания json, все остальное не про Go
А где вам часто требуется index, чтобы так по этому поводу переживать? Много писал на питоне, но чего-то не припомню, что хоть раз в реальном коде использовал. Без наезда, реально интересно
Я не силен в C, но кажется современные компиляторы должны вполне успешно это оптимизировать, особенно если переменная помечена явным способом, как константа