Go для быстрого обмена json-ками. Если вы пользуетесь чистой архитектурой, то валидацию вы проводите на уровне презентации, а не на уровне приложения, в то время как я использую протокол для описания интерфейсов (т.е. поведения) на уровне приложения. В библиотеках да, но в таких сервисах тоже да (ИМХО). Если у меня количество каналов уведомлений может расширятся, думаю ABC вполне уместен, с ним как бы даже попроще будет чем с композицией.
по п.3 не соглашусь, и даже не особо вникая в глубины программирования, можно сделать вывод: если наследование самая бесполезная штука в ООП, от нее бы отказались в принципе. Я активно использую наследование в разработке, и многие тоже. Наследование это управления повторным использованием кода. по п.2 хм...ну мысль тоже интересная..., однако плюс реализации через ABC, в том, что она гарантирует: валидация обязательно произойдет в строго определенный момент жизненного цикла объекта. Не вижу здесь нарушение инкапсуляции. Да и если определять валидаторы отдельно, их придется дергать в каждом классе, с другой стороны зачем их дергать если есть общая логика предварительной проверки. Например, вEmailNotification вообще нет необходимости прописывать валидацию. по п.1 Протоколы хороши для описания поведения, абстрактные классы необходимы, когда нужно передать общую реализацию или состояние. Если несколько классов не просто имеют одинаковый интерфейс, но и разделяют общую логику, ABC избавляет от дублирования.
Если я делаю большой backend я предпочитаю протоколы, с ними легче реализовать чистую архитектуру. Однако если у меня маленький сервис, типа сервиса уведомлений, где разделяется общая реализация, я бы использовал ABC, .
Мне статья понравилась. Считаю ее очень полезной. На мой взгляд автор просто показал возможности кэширования и как его настраивать в коде. Кэш кстати хранится всего 30 сек, так что на счет неактуальности данных это преувеличение. То что используются словари вместо модели pydantic...., ну собственно и что? Как я думаю такой подход более нагляден для начинающих программистов, да и автор дал ссылки на них в pastebin. Тем более для моделей необходим дополнительный пакет.
Да, пожизненная туфта. Договор на тех.поддержку это обязательно.
Go для быстрого обмена json-ками.
Если вы пользуетесь чистой архитектурой, то валидацию вы проводите на уровне презентации, а не на уровне приложения, в то время как я использую протокол для описания интерфейсов (т.е. поведения) на уровне приложения.
В библиотеках да, но в таких сервисах тоже да (ИМХО). Если у меня количество каналов уведомлений может расширятся, думаю ABC вполне уместен, с ним как бы даже попроще будет чем с композицией.
С конца наверное пойду:
по п.3 не соглашусь, и даже не особо вникая в глубины программирования, можно сделать вывод: если наследование самая бесполезная штука в ООП, от нее бы отказались в принципе. Я активно использую наследование в разработке, и многие тоже. Наследование это управления повторным использованием кода.
по п.2 хм...ну мысль тоже интересная..., однако плюс реализации через ABC, в том, что она гарантирует: валидация обязательно произойдет в строго определенный момент жизненного цикла объекта. Не вижу здесь нарушение инкапсуляции. Да и если определять валидаторы отдельно, их придется дергать в каждом классе, с другой стороны зачем их дергать если есть общая логика предварительной проверки. Например, в
EmailNotificationвообще нет необходимости прописывать валидацию.по п.1 Протоколы хороши для описания поведения, абстрактные классы необходимы, когда нужно передать общую реализацию или состояние. Если несколько классов не просто имеют одинаковый интерфейс, но и разделяют общую логику, ABC избавляет от дублирования.
Если я делаю большой backend я предпочитаю протоколы, с ними легче реализовать чистую архитектуру. Однако если у меня маленький сервис, типа сервиса уведомлений, где разделяется общая реализация, я бы использовал ABC, .
Ну что вы прям переживаете, так сложилось исторически :-)
Если многие могут сразу и быстро понять про что речь, то почему бы и нет...
Здесь скорее языковой момент: мы говорим "едем на машине", однако мы ведь тоже не на крыше едем, вроде правильнее сказать "в машине" :-)
Мне статья понравилась. Считаю ее очень полезной. На мой взгляд автор просто показал возможности кэширования и как его настраивать в коде. Кэш кстати хранится всего 30 сек, так что на счет неактуальности данных это преувеличение. То что используются словари вместо модели pydantic...., ну собственно и что? Как я думаю такой подход более нагляден для начинающих программистов, да и автор дал ссылки на них в pastebin. Тем более для моделей необходим дополнительный пакет.