Пример класса, нарушающего принципы SOLID

Рассмотрим простой класс, который управляет заказами и одновременно отвечает за их обработку и сохранение в файл.

class OrderProcessor:
def __init__$self$:
self.orders =
def add_order$self,order$:
self.orders.append$order$
def process_orders$self$:
for order in self.orders:
self._process_order$order$
def _process_order$self,order$:
# Здесь может быть сложная логика обработки заказа
print$f"Processingorder:order"$
def save_orders_to_file$self,filename$:
with open$filename{,}^{\prime }{w}^{\prime }$ as file:
for order in self.orders:
file.write(f"{order}\n")Проблемы сопровождаемости и тестируемости

Нарушение принципа единственной ответственности $SingleResponsibilityPrinciple-SRP$:
Класс OrderProcessor отвечает за управление заказами, их обработку и сохранение в файл. Это затрудняет его изменение и тестирование, так как изменение логики обработки может затронуть и функциональность сохранения.

Нарушение принципа открытости/закрытости $Open/ClosedPrinciple-OCP$:
Если мы захотим изменить способ сохранения заказов $например,сохранятьвбазуданныхвместофайла$, нам придется изменять существующий класс, что может привести к введению ошибок.

Нарушение принципа инверсии зависимостей $DependencyInversionPrinciple-DIP$:
Класс жестко зависит от реализации сохранения, что делает его трудным для тестирования $например,нужнобудетподменятьлогикупритестировании$.

Рефакторинг

Разобьем класс на несколько классов с четкими обязанностями и добавим интерфейсы.

from abc import ABC, abstractmethod
class Order:
def __init__$self,id,details$:
self.id = id
self.details = details
class OrderProcessor:
def __init__$self,orde{r}_{s}torage$:
self.orders = self.order_storage = order_storage
def add_order$self,order$:
self.orders.append$order$
def process_orders$self$:
for order in self.orders:
self._process_order$order$
def _process_order$self,order$:
# Логика обработки заказа
print$f"Processingorder:order.id"$
def save_orders$self$:
self.order_storage.save$self.orders$
class OrderStorage$ABC$:
@abstractmethod
def save$self,orders$:
pass
class FileOrderStorage$OrderStorage$:
def __init__$self,filename$:
self.filename = filename
def save$self,orders$:
with open$self.filename{,}^{\prime }{w}^{\prime }$ as file:
for order in orders:
file.write(f"{order.id}: {order.details}\n")
# Пример использования
order_storage = FileOrderStorage${}^{\prime }orders.tx{t}^{\prime }$ processor = OrderProcessor$orde{r}_{s}torage$
order1 = Order$1{,}^{\prime }Orderdetails{1}^{\prime }$ order2 = Order$2{,}^{\prime }Orderdetails{2}^{\prime }$
processor.add_order$order1$ processor.add_order$order2$ processor.process_orders processor.save_ordersУлучшения

Соблюдение принципа единственной ответственности: Каждый класс теперь отвечает за свою конкретную задачу: OrderProcessor управляет заказами и их обработкой, FileOrderStorage сохраняет заказы в файл.

Соблюдение принципа открытости/закрытости: Чтобы изменить способ хранения заказов, просто создадим новый класс, реализующий OrderStorage, без необходимости изменять OrderProcessor.

Соблюдение принципа инверсии зависимостей: Вместо жесткой зависимости от конкретного способа сохранения заказов мы используем интерфейс OrderStorage, что упрощает тестирование и замену реализаций.

Такой рефакторинг делает код более гибким, упрощает его сопровождение и тестирование, так как мы можем легко подменять зависимости и изменять поведение, не меняя основную логику.