Аккуратный код
Ответственность
Аккуратный код
Ответственность
В прошлых советах о чистоте кода мы проектировали бэкенд для системы, которая продаёт курсы и билеты на вебинары. Давайте теперь представим, что станет с этой системой через несколько месяцев существенных доработок. Скорее всего, за это время мы сделаем парочку выгрузок и печатных документов для бухгалтерии, добавим расчёт стоимости доставки, несколько уровней скидок, уведомления в Телеграме о количестве заказов в день и Эпл‑пей. Каждая из этих фич, скорее всего, оставит след в классе заказа, сделав его примерно таким:
Одни и те же задачи мы начнём решать по два раза. Программист, делающий выгрузку для бухгалтерии, напишет метод для расчёта НДС и положит его в класс Order. А его товарищ, занятый интеграцией с логистическим партнёром, — напишет точно такой же метод в своём классе PartnerIntegration, потому что просто не увидит результат работы первого.
Этого удастся избежать, если использовать принцип единой ответственности:
Давайте воспользуемся композицией, пусть класс заказа будет всего лишь интерфейсом для более специализированных классов:
class Order:
def __init__(self):
self.accounting = Accounting(order=self)
self.payment = PaymentSystem(order=self)
self.shipment = Shipper(order=self)
self.notifications = NotificationsDispatcher(order=self)
Мы разграничили ответственность за разные участки программы между разными классами. Теперь новому программисту гораздо легче догадаться, что расчёт НДС вызывается через order.accounting.get_vat(), а уведомление в Телеграме об успешном заказе он сразу полезет искать в order.notifications.
Этот приём можно применять и к нижележащим классам. Класс, который в примере выше отвечает за уведомления, называется NotificationDispatcher, и сразу понятно, что его задача — рассылать сигналы об изменениях в остальные части приложения. Можно послать один сигнал «заказ создан», чтобы на его основе сделали свою работу несколько классов — к примеру, уведомлятель в Телеграме и присылатель приветственного письма пользователю.
P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.