SOLID — это пять принципов проектирования для построения поддерживаемых, гибких OOP-систем. Каждый решает частую причину жесткого, хрупкого кода.
SOLID — это пять принципов проектирования для построения поддерживаемых, гибких OOP-систем. Каждый решает частую причину жесткого, хрупкого кода.
| Буква | Принцип | Смысл в одном предложении |
|---|
| S | Single Responsibility | У класса должна быть только одна причина для изменения |
| O | Open/Closed | Открыт для расширения, закрыт для модификации |
| L | Liskov Substitution | Подтипы должны быть пригодны там, где используется базовый тип |
| I | Interface Segregation | Много маленьких интерфейсов лучше одного большого |
| D | Dependency Inversion | Зависимость от абстракций, не от конкретных классов |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService не зависит от email специально — замените на SMS или test double без его изменения (D). Добавление нового типа уведомителя не требует изменений OrderService (O).
SOLID — это рекомендация, а не закон. Чрезмерное применение — интерфейс на класс, косвенность везде — приводит к "абстрактному супу", который сложнее отслеживать, чем исходную проблему.
SOLID дает общий диагностический язык: рецензенты могут назвать почему класс сложно менять ("это нарушает SRP"), вместо того чтобы спорить о вкусах.
Применяемые разумно, эти принципы снижают каскадные эффекты — изменения остаются локальными, новые функции расширяют, а не переписывают код, и тесты могут подменять реальные зависимости подделками.