Comments 12
В этой статье я покажу изящный прием, который превратит ваши многоэтажные условия в плоский, легко расширяемый и тестируемый код. Всего за 5 минут вы научитесь писать код, который коллеги будут показывать как пример для подражания.
Немного примеров match/case в Python 3.10
Существует уже 4 года. Не благодарите.
Меня зовут Михаил, я веду Telegram-канал «Python Шпильки», где делюсь изящными приемами программирования.
Спасибо, запомнил. Ни в коем случае не подписываться.
Очень много синтаксического мусора в виде низачем не нужных имён методов из-за отсутствия в питоне многострочных лямбд.
Когда не знал про паттерн "стратегия", но умеешь пользоваться LLM и генерировать ИИ-шит
то, что он класс не назвал Strategy, не означает, что он не реализовал данный паттерн лол))
у автора как раз таки и реализован паттерн стратегия, с некоторыми нюансами, но все же, для примера вполне достаточно.
есть хендлеры, есть условия, при которых выбирается нужный хендлер, есть дешевый мапинг. единственное, я бы сделал это в виде отдельных классов и не привязывался к классу OrderProceccor, тем самым создав пространство для масштабирования.
с чем вы тут не согласны?)))
Мне не нравится тем, что это AI-slop и LLM-shit
Но если предположить, что публикатор все же писал статью "вручную"...
Если ты пишешь тег "Паттерны проектирования" - то сошлись, что в этих самых паттернах такой подход называется стратегией.
Вообще, многие разработчики на питоне имеют какую-то антипатию к патернам, аппелируя к тому, что паттерны переусложнены и в них много лишнего - вот смотрите, как можно просто сделать, "тяп-ляп и в продакшн". В результате получается то, что получается - код, насквозь прошитый глобальными переменными, статическими сессиями и глобальными функциями с сайд-эффектами. Да-да, весь этот ад с reserve_inventory(...) - откуда у нее возьмется сессия, в которой она сходит в базу или другой микросервис? Или notify_customer_service(...) - откуда в нем возьмутся реквизиты для доступа к очередям рассылки уведомлений?
Такие простые реализации, которые смело копипастит из ответов LLM автор - без всей этой замученности с типами, классами и прочим - они в рабочей схеме не прокатят. Код хорошо бы прогонять через проверку статической типизации - вот эти вот все from typing import .... и mypy (это вообще категорическое требование - с моей точки зрения, код без них вообще недопустим, кроме случаев безжалостного легаси). А когда привозится статическая типизация, вот тогда и начинается самое интересное - то есть то, чего начинающие разработчики не любят.
Ну а то, что показано в статье - поытка разделить god method - но в результате просто превращает его в god object. Но LLM на это пофиг, чушь на входе - чушь на выходе, обучили на спагетти из статиков, глобальных переменных и сайдэффектов - получите то же самое в ответ на свой запрос. И следующую итерацию обучат на этом же генеративе. Идеальная самоодебиливающаяся система, которая учится быть еще тупее на своем же выхлопе.
В случае чуть более-менее сложных логик, описываемый подход (с использованием словаря обработчиков, где значения - обработчики, а ключи - строки воходных логических параметров) все равно значительно лучше, чем как match/case, так и паттерна стратегия, ИМХО. Таким подходом еще деды на ассемблере пользовались. Он прост и надежен, как АК-47.
Если есть обоснованное предположение, что структура функций не будет меняться, либо более сложная логика появится только в редких статус-обработчиках, можно еще больше упростить.
class OrderProcessor:
def __init__(self):
self.handlers = {
"new": [validate_order, process_payment, send_confirmation_email],
...
}
def __call__(self, order_data):
status = order_data['status']
if status in self.handlers:
for handler in self.handlers[status]:
reuslt = handler(order_data)
else:
logger.warning(f"Unknown order status: {status}")
result = {"error": "Unknown status"}
return result
а теперь можно просто выкладывать сгенерированный текст ИИ просто в качестве статьи и называть это Best Practices?
Это же просто копипаст ответа курсора)
Спасибо за комментарии! Тапок у меня теперь … немерено. Я предложил один из вариантов обхода if-elif-else, и попытался описать этот подход как можно понятнее. Согласен что есть и другие подходы, которые вы написали, за это вам отдельное спасибо!!! Пусть каждый выбирает себе по душе.
Python шпильки: как заменить многоэтажные if-else на изящный словарь функций