1. SRP соблюдён — OrderHelper занимается только логикой работы с заказами.
2. DIP соблюдён — зависит от переданного client, а не от конкретной реализации.
3. Слабая связанность — можно подставить любой client.
4. Тестируемость — легко мокать client.
Даже если хочется сделать общий фасад, можно так:
class Facade:
def __init__(self, db, http, grpc):
self.db = db
self.http = http
self.grpc = grpc
class Order:
def __init__(self, facade: Facade):
self.facade = facade
1. Единая точка входа — все зависимости в одном месте.
2. Легко мокать — можно подменить хоть весь facade.
3. Гибкость — можно менять реализацию facade.
4. Контроль — чётко видно, что нужно Order.
Возможно, мой код сложнее.
• Сложнее локально, но проще глобально.
• Попробуйте написать 10 разных тестов для каждого подхода.
• Попробуйте заменить clients на другую реализацию.
Зачем усложнять простую задачу?
Потому, что простая задача завтра станет сложной:
• Добавится логирование.
• Появятся ретраи.
• Метрики.
• Кеширование.
• Новый клиент.
По итогу, что мы имеем:
1. Масштабируемость — подход работает для 1000+ тестов.
2. Поддерживаемость — легко изменять и расширять.
3. Тестируемость — можно тестировать любые сценарии.
4. Переносимость — легко адаптировать под разные фреймворки, менять бэкэнд.
5. Отладка — чётко видно, что происходит, где входная точка и т.д.
Я видел разные тренинги и большинство учат работать с той или иной технологией, но почти никто не учить писать так, чтобы фреймворк был поддерживаемым и расширяемым и эту нишу я пытаюсь заполнить.
——————————-
📱 TG-сообщество
📱 Обучение
📱 Отзывы