**SOLID** - это абревиатура из пяти принципов объектно-ориентированного программирования (ООП) 1. **S - Single Responsibility Principle** (Принцип единственной ответственности) Класс должен иметь только одну причину для изменения. Каждый класс должен отвечать только за одну задачу. *Плохо:* ``` class User:    def save_to_db(self):        # сохраняет в БД        pass    def send_email(self):        # отправляет email        pass    def log_activity(self):        # пишет логи        pass ``` Один класс делает 3 разные вещи. Если изменится логика email придётся править User, хотя он не только про User. *Хорошо:* ``` class User:    def save(self):        pass  class EmailService:    def send(self, user):      pass class Logger:    def log(self, action):        pass ``` **2. O - Open/Closed Principle (OCP)** Классы должны быть открыты для расширения, но закрыты для модификации. *Плохо:* Представь, что у тебя есть кафе, и кассир умеет считать только два типа скидок: • 10% скидка по карте, • 50 рублей скидка по акции. Каждый раз, когда появляется новая акция (например, «второй кофе бесплатно» или «бесплатный десерт при заказе на 500+ рублей»), приходится переделывать работу кассира заново, переобучать его, менять инструкции. Это риск ошибок и затраты времени. *Хорошо:* Теперь представь, что у тебя в кафе не кассир вручную считает скидку, а есть система правил скидок: • У кассира есть «коробка», куда можно положить любое правило расчёта скидки. • Сама работа кассира не меняется: он всегда берёт чек → применяет «коробку со скидкой» → озвучивает итоговую цену. • Чтобы добавить новую акцию, ты просто кладёшь в коробку ещё одно правило (например, «второй кофе бесплатно»). • Сам кассир работает так же, менять его инструкции не нужно. **3. L - Liskov Substitution Principle (LSP)** Объекты подтипов должны быть взаимозаменяемы с объектами их базового типа. Если B наследуется от A, то B должен **полностью заменять** A без нарушения логики. 4. **I - Interface Segregation Principle (ISP)** Клиенты не должны зависеть от интерфейсов, которые они не используют. Разделяй большие интерфейсы на **мелкие и специфичные**. Лучше много маленьких интерфейсов, чем один большой. 5. **D - Dependency Inversion Principle (DIP)** Зависимость должна быть от абстракций, а не от конкретных реализаций. Высокоуровневые модули не должны зависеть от низкоуровневых. Оба должны зависеть от абстракций.