Что плохого если менять поведение класса

Ключевые проблемы изменения поведения класса

Изменение поведения существующего класса — это один из самых опасных антипаттернов в разработке программного обеспечения, который нарушает принцип подстановки Барбары Лисков (LSP) из SOLID и ведет к хрупкости системы.

Основные проблемы и риски

1. Нарушение принципа подстановки Лисков (LSP) Это фундаментальная проблема: клиенты класса ожидают определенного поведения, основанного на контракте класса (его публичном API и неявных гарантиях). Изменение этого поведения ломает эти ожидания.

// Было
class PaymentProcessor {
    public void processPayment(double amount) {
        // Всегда списывает всю сумму
        account.withdraw(amount);
    }
}

// Клиентский код полагается на это поведение
processor.processPayment(100.0); // Списывается 100

// Изменили поведение
class PaymentProcessor {
    public void processPayment(double amount) {
        // Теперь списывает только если баланс > amount*2
        if (account.getBalance() > amount * 2) {
            account.withdraw(amount);
        }
    }
}
// Клиентский код сломался!

2. Побочные эффекты в наследуемых классах Если класс является родительским для других классов, изменение его поведения может сломать всех потомков:

open class BaseRepository {
    open fun save(data: Data) {
        // Сохранение в базу данных
        database.insert(data)
    }
}

class CachedRepository : BaseRepository() {
    override fun save(data: Data) {
        cache.put(data.id, data)
        super.save(data) // Полагается на родительскую реализацию
    }
}

// Если изменить BaseRepository.save() так, чтобы он логировал данные,
// это может сломать CachedRepository

3. Проблемы с тестированием

• Существующие юнит-тесты перестают работать, так как они проверяли старое поведение
• Интеграционные тесты могут начать падать из-за неожиданных изменений
• Приходится переписывать тесты, что увеличивает стоимость поддержки

4. Нарушение обратной совместимости Если ваш класс является частью библиотеки или API, изменение поведения ломает обратную совместимость. Клиенты вашей библиотеки будут вынуждены менять свой код, что недопустимо для публичных API.

Правильные альтернативы

1. Создание нового класса через наследование

open class OriginalProcessor {
    fun process() { /* оригинальная логика */ }
}

class ModifiedProcessor : OriginalProcessor() {
    override fun process() { /* новая логика */ }
}

2. Использование композиции

class NewBehaviorProcessor(
    private val originalProcessor: OriginalProcessor
) {
    fun process() {
        // Дополнительная логика
        originalProcessor.process()
        // Или полностью новая реализация
    }
}

3. Паттерн Стратегия

interface ProcessingStrategy {
    void process();
}

class OriginalStrategy implements ProcessingStrategy {
    public void process() { /* старая логика */ }
}

class NewStrategy implements ProcessingStrategy {
    public void process() { /* новая логика */ }
}

class Context {
    private ProcessingStrategy strategy;
    
    public void setStrategy(ProcessingStrategy strategy) {
        this.strategy = strategy;
    }
    
    public void execute() {
        strategy.process();
    }
}

4. Параметризация поведения

class ConfigurableProcessor(
    private val enableNewBehavior: Boolean = false
) {
    fun process() {
        if (enableNewBehavior) {
            newLogic()
        } else {
            originalLogic()
        }
    }
}

Когда изменение поведения допустимо

1. Исправление критических багов, которые нарушают контракт класса
2. Оптимизация производительности без изменения внешнего поведения
3. Рефакторинг с сохранением всех гарантий и контрактов
4. Ранние стадии проекта, когда API еще не стабилизировался

Лучшие практики

• Сначала добавляйте, потом удаляйте: добавляйте новые методы/классы, объявите старые как deprecated, удаляйте только через несколько версий
• Семантическое версионирование: изменение поведения = мажорная версия (2.0.0 вместо 1.1.0)
• Подробная документация: явно документируйте все изменения поведения
• Полное покрытие тестами: убедитесь, что тесты покрывают как старое, так и новое поведение

Изменение поведения существующего класса — это красный флаг в архитектуре приложения, который говорит о недостаточном проектировании или нарушении принципов SOLID. Всегда предпочитайте расширение модификации, особенно в долгосрочных проектах.