Может ли класс наследник переопределить метод класса родителя?

Переопределение методов класса в наследнике

Это важный вопрос, касающийся одного из фундаментальных принципов ООП — полиморфизма. Ответ зависит от того, какой метод мы обсуждаем: instance метод или static метод.

Instance методы: ДА, переопределяются (Override)

Instance методы (обычные методы) могут и должны переопределяться в классах-наследниках. Это называется method overriding и является основой полиморфизма.

// Класс родитель
public class Animal {
    // Instance метод (можно переопределить)
    public void makeSound() {
        System.out.println("Издаёт звук");
    }
    
    // Instance метод
    public void move() {
        System.out.println("Животное движется");
    }
}

// Класс наследник
public class Dog extends Animal {
    @Override  // Аннотация для явного указания на переопределение
    public void makeSound() {
        System.out.println("Гав-гав!");  // Переопределили
    }
    
    @Override
    public void move() {
        System.out.println("Собака бегает");  // Переопределили
    }
}

// Использование
public static void main(String[] args) {
    Animal animal = new Dog();
    animal.makeSound();  // Вывод: "Гав-гав!" (использовано переопределённое)
    animal.move();       // Вывод: "Собака бегает" (использовано переопределённое)
}

Ключевой момент: вызывается VERSION НА ОСНОВЕ ТИПА ОБЪЕКТА, а не типа переменной:

Animal dog = new Dog();
dog.makeSound();  // ДИНАМИЧЕСКАЯ ДИСПЕТЧЕРИЗАЦИЯ
// Компилятор видит: Animal
// Runtime видит: Dog → вызывает Dog.makeSound()

Dog realDog = new Dog();
realDog.makeSound();  // Также вызывает Dog.makeSound()

Static методы: НЕТ, скрываются (Hide)

Static методы НЕ переопределяются, а скрываются (hidden). Это важное различие!

// Класс родитель
public class Parent {
    public static void staticMethod() {
        System.out.println("Static метод из Parent");
    }
    
    public void instanceMethod() {
        System.out.println("Instance метод из Parent");
    }
}

// Класс наследник
public class Child extends Parent {
    // Это НЕ переопределение, а СКРЫТИЕ (hiding)
    public static void staticMethod() {  // Без @Override или с ошибкой
        System.out.println("Static метод из Child");
    }
    
    @Override  // Правильное переопределение
    public void instanceMethod() {
        System.out.println("Instance метод из Child");
    }
}

// Использование
public static void main(String[] args) {
    Parent parent = new Child();
    
    // Instance метод → ПОЛИМОРФИЗМ (вызвется Child версия)
    parent.instanceMethod();    // Вывод: "Instance метод из Child"
    
    // Static метод → НЕ полиморфизм (вызвется Parent версия)
    parent.staticMethod();       // Вывод: "Static метод из Parent"
    
    // Явный вызов через Child
    Child.staticMethod();        // Вывод: "Static метод из Child"
}

Почему так происходит?

Static методы привязаны к классу, а не к объекту. Компилятор определяет, какой метод вызывать, исходя из типа переменной, а не типа объекта:

Parent p = new Child();
p.staticMethod();     // Компилятор видит: Parent → вызывает Parent.staticMethod()

Child c = new Child();
c.staticMethod();     // Компилятор видит: Child → вызывает Child.staticMethod()

Abstract методы: ДОЛЖНЫ быть переопределены

Abstract методы НЕ имеют реализации и ОБЯЗАНЫ быть переопределены в подклассе (если подкласс не abstract).

// Abstract класс
public abstract class Shape {
    // Abstract метод (нет body)
    abstract void draw();     // ДОЛЖЕН быть переопределён
    
    // Обычный метод
    public void display() {
        System.out.println("Отображение фигуры");
    }
}

// Конкретный класс ДОЛЖЕН переопределить draw()
public class Circle extends Shape {
    @Override
    void draw() {
        System.out.println("Рисуем круг");
    }
    
    @Override  // Опционально
    public void display() {
        super.display();  // Можем вызвать родительскую версию
        System.out.println("Это окружность");
    }
}

// Ошибка: Circle2 не переопределил draw()
public class Circle2 extends Shape {
    // ❌ Ошибка компиляции: abstract method not overridden
}

Final методы: НЕ могут быть переопределены

Final методы запрещены для переопределения на уровне языка.

public class Parent {
    public final void criticalMethod() {
        System.out.println("Этот метод нельзя переопределить");
    }
}

public class Child extends Parent {
    // ❌ ОШИБКА КОМПИЛЯЦИИ
    @Override
    public void criticalMethod() {  // Cannot override final method
        System.out.println("...");
    }
}

Когда использовать final:

public class Parent {
    // Final: это поведение не должно менять
    public final void securityCheck() {
        // Критичная проверка безопасности
        validateUser();
        validatePermissions();
        // Наследники не должны менять эту логику
    }
    
    // Можно переопределить
    protected void performAction() {
        // Наследники могут переопределить
    }
}

Private методы: видны только в текущем классе

Private методы вообще не видны наследникам и не могут быть переопределены.

public class Parent {
    private void secretMethod() {  // Private — видна только тут
        System.out.println("Секретный метод");
    }
    
    public void publicMethod() {
        secretMethod();  // Вызов из самого класса OK
    }
}

public class Child extends Parent {
    // Это НЕ переопределение, это НОВЫЙ метод с тем же именем
    public void secretMethod() {
        System.out.println("Другой метод в Child");
    }
    
    // Даже если вызовем через Parent
    Child c = new Child();
    c.publicMethod();      // Вызовет Parent.secretMethod(), не Child.secretMethod()
}

Правила переопределения (Override Contract)

Когда переопределяете метод, должны соблюдать контракт:

public class Parent {
    public List<String> getData() {  // Возвращает List
        return new ArrayList<>();
    }
    
    public void process(Object obj) {  // Принимает Object
        // ...
    }
}

public class Child extends Parent {
    // ✅ ПРАВИЛЬНО: ковариантный возвращаемый тип
    @Override
    public ArrayList<String> getData() {  // ArrayList это подтип List
        return new ArrayList<>();
    }
    
    // ✅ ПРАВИЛЬНО: контравариантные параметры
    @Override
    public void process(String str) {  // String это подтип Object
        // ...
    }
    
    // ✅ ПРАВИЛЬНО: может выбросить более узкие исключения
    @Override
    public void risky() throws IOException {  // Было throws Exception
        // ...
    }
    
    // ❌ НЕПРАВИЛЬНО: нельзя менять модификатор доступа
    @Override
    private void badOverride() {  // Было public — ошибка!
        // ...
    }
}

Таблица: Переопределение методов

Практический пример: правильно структурированный класс

public abstract class DataProcessor {
    // Private — только для внутреннего использования
    private void validateInput(String data) {
        if (data == null || data.isEmpty()) {
            throw new IllegalArgumentException();
        }
    }
    
    // Protected — может быть переопределён наследниками
    protected void beforeProcessing() {
        System.out.println("Подготовка к обработке");
    }
    
    // Abstract — ДОЛЖЕН быть переопределён
    protected abstract void doProcess(String data);
    
    // Public template method — не переопределяется
    public final void process(String data) {
        validateInput(data);        // Private, не видна наследнику
        beforeProcessing();         // Может быть переопределена
        doProcess(data);           // Абстрактный, должна быть реализована
        afterProcessing();         // Может быть переопределена
    }
    
    // Protected — может быть переопределена
    protected void afterProcessing() {
        System.out.println("Завершение обработки");
    }
    
    // Static — скрывается, не полиморфна
    public static String getVersion() {
        return "1.0";
    }
}

Вывод

Может ли наследник переопределить метод родителя?

• Instance методы → ✅ ДА, ВСЕГДА
• Static методы → ❌ НЕТ, они скрываются
• Final методы → ❌ НЕТ, запрещено
• Private методы → ❌ НЕТ, не видны
• Abstract методы → ✅ ДА, ОБЯЗАТЕЛЬНО

Это один из краеугольных камней понимания ООП и полиморфизма в Java.