Будет ли нарушением принципа открытости/закрытости, если поменять интерфейс в классе наследника?

# Open/Closed Principle и изменение интерфейса в подклассе

Это отличный вопрос о нарушении принципа Open/Closed (O из SOLID). Коротко: ДА, это нарушение. Разберу подробно.

1. Open/Closed Principle (OCP)

Принцип гласит:

• Открыто для расширения (extension)
• Закрыто для модификации (modification)

Это означает: добавляй новый функционал без изменения существующего кода.

# ✅ ПРАВИЛЬНО - открыто для расширения
class Animal:
    def make_sound(self):
        pass

class Dog(Animal):
    def make_sound(self):
        return "Woof!"

class Cat(Animal):
    def make_sound(self):
        return "Meow!"

# Используем существующий код без изменений
for animal in [Dog(), Cat()]:
    print(animal.make_sound())

2. Нарушение OCP через изменение интерфейса

Проблема 1: Изменение сигнатуры метода

# ❌ НАРУШЕНИЕ OCP
class Shape:
    def area(self):
        pass

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius
    
    # Изменяем интерфейс родителя!
    def area(self, precision=2):
        return round(3.14 * self.radius ** 2, precision)

# Проблема: тип Circle не совместим с Shape
shapes: list[Shape] = [Circle(5)]
for shape in shapes:
    # Это может сломаться!
    print(shape.area())  # OK - работает
    print(shape.area(precision=3))  # AttributeError на других классах!

Проблема 2: Изменение возвращаемого типа

# ❌ НАРУШЕНИЕ OCP
class Database:
    def get_user(self, user_id: int) -> User:
        pass

class PostgresDatabase(Database):
    def get_user(self, user_id: int) -> dict:  # Изменили тип!
        return {"id": user_id, "name": "Alice"}

# Проблема в коде:
def process_user(db: Database):
    user = db.get_user(1)
    # Ожидаем User, но получаем dict
    print(user.name)  # AttributeError!

Проблема 3: Добавление обязательных параметров

# ❌ НАРУШЕНИЕ OCP
class Logger:
    def log(self, message: str):
        pass

class FileLogger(Logger):
    def log(self, message: str, level: str = "INFO"):
        pass  # Добавили параметр

# Весь существующий код ломается:
logger: Logger = FileLogger()
logger.log("Error")  # OK
logger.log("Error", "ERROR")  # OK

# Но если подкласс требует level:
class StrictFileLogger(Logger):
    def log(self, message: str, level: str):  # level обязателен!
        pass

logger: Logger = StrictFileLogger()
logger.log("Error")  # TypeError: missing required argument 'level'

3. Это нарушение принципа Liskov Substitution (LSP)

Liskov Substitution Principle (L из SOLID): Подкласс должен быть заменяем для своего базового класса

class Bird:
    def fly(self) -> str:
        return "Flying..."

class Penguin(Bird):
    def fly(self) -> str:
        raise NotImplementedError("Пингвины не летают")  # Нарушение LSP!

# Код сломается:
def move_bird(bird: Bird):
    print(bird.fly())  # Ожидаем полет

move_bird(Penguin())  # RuntimeError!

4. Правильный подход: Composition вместо Inheritance

Вариант 1: Правильная иерархия

# ✅ ПРАВИЛЬНО - не нарушаем OCP/LSP
class Bird:
    def move(self) -> str:
        pass

class FlyingBird(Bird):
    def move(self) -> str:
        return "Flying..."

class SwimmingBird(Bird):
    def move(self) -> str:
        return "Swimming..."

class Penguin(SwimmingBird):  # Пингвин - это плывущая птица
    def move(self) -> str:
        return "Waddling and swimming..."

# Используем:
def move_bird(bird: Bird):
    print(bird.move())

move_bird(Penguin())  # OK - не нарушаем контракт

Вариант 2: Composition

# ✅ ПРАВИЛЬНО - composition вместо inheritance
class MovementBehavior:
    def move(self) -> str:
        pass

class FlyBehavior(MovementBehavior):
    def move(self) -> str:
        return "Flying..."

class SwimBehavior(MovementBehavior):
    def move(self) -> str:
        return "Swimming..."

class Bird:
    def __init__(self, behavior: MovementBehavior):
        self.behavior = behavior
    
    def move(self) -> str:
        return self.behavior.move()

# Использование:
early_bird = Bird(FlyBehavior())
penguin = Bird(SwimBehavior())

print(early_bird.move())  # Flying...
print(penguin.move())  # Swimming...

5. Практический пример нарушения

# ❌ ПЛОХО - нарушение OCP/LSP
from typing import Optional

class PaymentProcessor:
    def process(self, amount: float) -> bool:
        pass

class CreditCardProcessor(PaymentProcessor):
    def process(self, amount: float, cvv: str) -> bool:  # Добавили параметр!
        # Процесс платежа
        return True

class PayPalProcessor(PaymentProcessor):
    def process(self, amount: float) -> bool:
        # Процесс платежа
        return True

# Код, который работает с интерфейсом:
class Order:
    def __init__(self, processor: PaymentProcessor):
        self.processor = processor
    
    def pay(self, amount: float):
        success = self.processor.process(amount)  # Не работает с CreditCardProcessor!
        return success

# Использование:
order = Order(CreditCardProcessor())
order.pay(100)  # TypeError!

6. Правильное решение

# ✅ ПРАВИЛЬНО - соблюдаем OCP/LSP
from typing import Optional
from dataclasses import dataclass

@dataclass
class PaymentInfo:
    amount: float
    method_data: dict  # Гибкие данные для разных методов

class PaymentProcessor:
    def process(self, payment: PaymentInfo) -> bool:
        pass

class CreditCardProcessor(PaymentProcessor):
    def process(self, payment: PaymentInfo) -> bool:
        cvv = payment.method_data.get('cvv')
        # Процесс платежа
        return True

class PayPalProcessor(PaymentProcessor):
    def process(self, payment: PaymentInfo) -> bool:
        email = payment.method_data.get('email')
        # Процесс платежа
        return True

class Order:
    def __init__(self, processor: PaymentProcessor):
        self.processor = processor
    
    def pay(self, amount: float, method_data: dict):
        payment = PaymentInfo(amount, method_data)
        success = self.processor.process(payment)  # Работает для всех!
        return success

7. Как проверить нарушение OCP

# Если тебе нужно делать isinstance или type checks:
if isinstance(processor, CreditCardProcessor):
    processor.process(amount, cvv)  # ❌ НАРУШЕНИЕ OCP!
else:
    processor.process(amount)

# То это признак нарушения Open/Closed Principle

Ключевые выводы:

• ДА, это нарушение Open/Closed Principle
• Также нарушение Liskov Substitution Principle (L из SOLID)
• Изменение интерфейса означает, что подкласс не заменяем
• Решение: правильная иерархия классов или composition
• Правило большого пальца: если в коде нужны isinstance проверки, нарушена иерархия
• Контракт класса священен - не меняй его в подклассах