PrepBro
← Назад к вопросам

Не противоречит ли переопределение в ООП программной инженерии

3.0 Senior🔥 91 комментариев
#SOLID и паттерны проектирования#ООП

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI22 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Не противоречит ли переопределение в ООП принципам программной инженерии

Краткий ответ

Нет, не противоречит. Переопределение (overriding) методов — это фундаментальная часть полиморфизма, который является краеугольным камнем ООП. Но! Только если использовать его правильно в соответствии с принципами SOLID, особенно Liskov Substitution Principle (LSP).

Что такое переопределение (Overriding)

// Базовый класс
public class Animal {
    public void makeSound() {
        System.out.println("Some generic sound");
    }
}

// Переопределение (overriding) в подклассе
public class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Woof!");
    }
}

public class Cat extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Meow!");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal dog = new Dog();
        Animal cat = new Cat();
        
        dog.makeSound();  // Woof!
        cat.makeSound();  // Meow!
        
        // Полиморфизм: один интерфейс, разные реализации
    }
}

Переопределение и Liskov Substitution Principle

LSP гласит: "Объекты подклассов должны корректно заменять объекты базового класса"

// ✅ ПРАВИЛЬНОЕ переопределение (соответствует LSP)
public class Rectangle {
    protected int width;
    protected int height;
    
    public void setWidth(int width) {
        this.width = width;
    }
    
    public void setHeight(int height) {
        this.height = height;
    }
    
    public int getArea() {
        return width * height;
    }
}

public class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        this.width = width;
        this.height = width;  // Квадрат имеет равные стороны
    }
    
    @Override
    public void setHeight(int height) {
        this.width = height;
        this.height = height;
    }
}

// ✅ Правильное использование: Square может заменить Rectangle
public class TestCorrect {
    public static void main(String[] args) {
        Rectangle rect = new Square();
        rect.setWidth(5);
        rect.setHeight(10);
        System.out.println(rect.getArea());  // 100 (5*5, затем 10*10) — ожидаемо
    }
}

// ❌ НЕПРАВИЛЬНОЕ переопределение (нарушает LSP)
public class BadCircle extends Shape {
    private double radius;
    
    @Override
    public void setWidth(int width) {
        // Окружность не имеет ширины!
        // Это нарушает контракт Shape
        throw new UnsupportedOperationException();
    }
    
    @Override
    public int getArea() {
        return (int)(Math.PI * radius * radius);
    }
}

// ❌ Это нарушит код, работающий с Shape
public void testBad() {
    Shape shape = new BadCircle();
    shape.setWidth(5);  // Вызывает UnsupportedOperationException!
}

Переопределение и другие принципы SOLID

1. Single Responsibility Principle (SRP)

// ✅ Правильно: каждый класс отвечает за свой тип платежа
public interface PaymentProcessor {
    void process(Payment payment);
}

public class CreditCardProcessor implements PaymentProcessor {
    @Override
    public void process(Payment payment) {
        // Логика обработки кредитной карты
        validateCard(payment);
        chargeCard(payment);
        logTransaction(payment);
    }
}

public class PayPalProcessor implements PaymentProcessor {
    @Override
    public void process(Payment payment) {
        // Логика обработки PayPal
        authenticatePayPal(payment);
        transferMoney(payment);
        logTransaction(payment);
    }
}

// ❌ Неправильно: один класс делает слишком много
public class UniversalProcessor {
    public void processPayment(String type, Payment payment) {
        if ("creditcard".equals(type)) {
            validateCard(payment);
            chargeCard(payment);
        } else if ("paypal".equals(type)) {
            authenticatePayPal(payment);
            transferMoney(payment);
        } else if ("crypto".equals(type)) {
            // ...
        }
        logTransaction(payment);
    }
}

2. Open/Closed Principle (OCP)

// ✅ Открыто для расширения, закрыто для модификации
public abstract class Vehicle {
    public abstract int getFuelEfficiency();
}

public class Car extends Vehicle {
    @Override
    public int getFuelEfficiency() {
        return 25;  // миль на галлон
    }
}

public class Truck extends Vehicle {
    @Override
    public int getFuelEfficiency() {
        return 15;
    }
}

// Добавляем новый тип?
// Просто расширяем Vehicle — не нужно менять существующий код!
public class ElectricCar extends Vehicle {
    @Override
    public int getFuelEfficiency() {
        return 100;  // эквивалент mpg
    }
}

// ❌ Неправильно: нарушает OCP
public class FuelCalculator {
    public int calculateFuel(Vehicle vehicle, int miles) {
        if (vehicle instanceof Car) {
            return miles / 25;
        } else if (vehicle instanceof Truck) {
            return miles / 15;
        } else if (vehicle instanceof ElectricCar) {
            // Нужно менять код при добавлении нового типа!
            return 0;
        }
        return 0;
    }
}

3. Dependency Inversion Principle (DIP)

// ✅ Зависимость от интерфейса, не от конкретной реализации
public interface Logger {
    void log(String message);
}

public class ConsoleLogger implements Logger {
    @Override
    public void log(String message) {
        System.out.println(message);
    }
}

public class FileLogger implements Logger {
    @Override
    public void log(String message) {
        // Пишем в файл
    }
}

public class Service {
    private final Logger logger;
    
    // Инъекция зависимости
    public Service(Logger logger) {
        this.logger = logger;
    }
    
    public void doWork() {
        logger.log("Working...");
        // logger может быть любой реализацией Logger
    }
}

// ❌ Неправильно: зависит от конкретного класса
public class BadService {
    private final ConsoleLogger logger = new ConsoleLogger();  // Жёсткая зависимость
    
    public void doWork() {
        logger.log("Working...");
        // Если нужен FileLogger, нужно переписывать класс
    }
}

Переопределение и инкапсуляция

// ✅ Правильное переопределение с сохранением контракта
public class BankAccount {
    private double balance;
    
    public void withdraw(double amount) {
        if (amount > balance) {
            throw new InsufficientFundsException();
        }
        balance -= amount;
    }
}

public class SavingsAccount extends BankAccount {
    @Override
    public void withdraw(double amount) {
        // Сбережения могут быть сняты не чаще 3 раз в месяц
        if (monthlyWithdrawals >= 3) {
            throw new WithdrawalLimitExceededException();
        }
        monthlyWithdrawals++;
        super.withdraw(amount);  // Сохраняем контракт базового класса
    }
}

// ❌ Неправильное переопределение
public class BadSavingsAccount extends BankAccount {
    @Override
    public void withdraw(double amount) {
        // Это противоречит контракту: BankAccount.withdraw() всегда выполняется
        throw new UnsupportedOperationException("Нельзя снять деньги из savings");
    }
}

Переопределение vs Перегрузка (Overloading)

// ✅ Перегрузка (overloading) — разные сигнатуры
public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }
    
    public double add(double a, double b) {
        return a + b;
    }
    
    public String add(String a, String b) {
        return a + b;
    }
}

// ✅ Переопределение (overriding) — одинаковая сигнатура, разная реализация
public interface Shape {
    double getArea();
}

public class Circle implements Shape {
    @Override
    public double getArea() {
        return Math.PI * radius * radius;
    }
}

public class Rectangle implements Shape {
    @Override
    public double getArea() {
        return width * height;
    }
}

Правильное использование переопределения

// ✅ Хорошая иерархия: Liskov Substitution Principle соблюдается
public abstract class Document {
    public abstract void open();
    public abstract void save();
    public abstract void close();
}

public class PdfDocument extends Document {
    @Override
    public void open() {
        // Открываем PDF
    }
    
    @Override
    public void save() {
        // Сохраняем PDF
    }
    
    @Override
    public void close() {
        // Закрываем PDF
    }
}

public class WordDocument extends Document {
    @Override
    public void open() {
        // Открываем Word
    }
    
    @Override
    public void save() {
        // Сохраняем Word
    }
    
    @Override
    public void close() {
        // Закрываем Word
    }
}

// Использование полиморфизма
public class DocumentManager {
    public void processDocument(Document doc) {
        doc.open();
        // редактируем
        doc.save();
        doc.close();
        // Document может быть любого типа!
    }
}

Когда переопределение становится проблемой

// ❌ Антипаттерн: нарушение контракта базового класса
public class Stack<T> {
    public void push(T item) {
        // Добавляем элемент в стек
    }
}

public class BadQueue<T> extends Stack<T> {
    @Override
    public void push(T item) {
        // Это добавляет в очередь (FIFO), а не стек (LIFO)!
        // Нарушает LSP
    }
}

// ❌ Антипаттерн: изменение поведения неожиданно
public class StringList extends ArrayList<String> {
    @Override
    public boolean add(String item) {
        // Добавляем только если длина > 5
        if (item.length() > 5) {
            return super.add(item);
        }
        return false;  // Но вызывающий код ожидает стандартное поведение!
    }
}

Таблица: Правильное vs неправильное переопределение

Аспект✅ Правильное❌ Неправильное
КонтрактСохраняет контракт базового классаНарушает контракт
ИсключенияВыбрасывает то же или более специфичноеВыбрасывает новые типы исключений
ВидимостьУвеличивает или оставляет (public → public)Уменьшает видимость (public → private)
Возвращаемый типКовариантен (подтип или тот же)Полностью другой тип
ЛогикаРасширяет функциональностьПолностью меняет поведение
LSPСоблюдает LSPНарушает LSP

Заключение

Переопределение (overriding) НЕ противоречит программной инженерии, если:

  1. Соблюдается Liskov Substitution Principle — подкласс может заменять базовый класс
  2. Сохраняется контракт — поведение соответствует ожиданиям
  3. Соблюдаются SOLID принципы — особенно SRP, OCP, DIP
  4. Правильно используется полиморфизм — разные реализации одного интерфейса

Переопределение КОНФЛИКТУЕТ с инженерией, если:

  • ❌ Нарушается LSP (подкласс неправильно заменяет базовый класс)
  • ❌ Меняется контракт метода без уважительной причины
  • ❌ Создаёт неожиданное поведение (принцип least surprise)
  • ❌ Используется вместо композиции

Общее правило: Переопределение — это инструмент полиморфизма. Если ты используешь его для расширения и уточнения поведения (а не для его кардинального изменения), то всё правильно.

Не противоречит ли переопределение в ООП программной инженерии | PrepBro