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

Нет. Закрытый (private) метод не наследуется, поэтому объявление метода с такой же сигнатурой в классе-наследнике не является переопределением, а создаёт независимый метод. Аннотация @Override для него вызовет ошибку компиляции.

Исторический контекст

Механизм доступа private предназначен для сокрытия деталей реализации внутри самого класса. Чтобы базовый класс мог менять внутреннюю реализацию, не создавая контракт для наследников, его закрытые методы не участвуют в переопределении и полиморфном вызове.

Это отделяет внутреннюю реализацию класса от его расширяемого API. Если метод должен быть точкой расширения для наследников, его обычно объявляют как protected или public, явно формируя такой контракт.

Постановка проблемы

Разработчик может увидеть одинаковые имена и сигнатуры в базовом классе и наследнике и ошибочно решить, что вызов будет полиморфным. Тогда вызов из метода базового класса продолжит обращаться к закрытому методу базового класса, даже если фактический объект является экземпляром наследника.

Такая ошибка особенно опасна в шаблонах проектирования и фреймворках: наследник выглядит так, будто переопределяет внутренний шаг алгоритма, но этот шаг вообще не вызывается. Изменение private на protected исправляет расширяемость, но одновременно увеличивает поверхность API и связывает базовый класс с наследниками.

Подробное решение

Закрытый метод доступен только коду, находящемуся в том классе, где он объявлен. Он не становится членом, который наследник может переопределить. Поэтому одноимённый метод наследника имеет самостоятельную декларацию и не заменяет метод базового класса.

При компиляции вызов закрытого метода из самого базового класса связывается с методом базового класса. Динамический тип объекта не выбирает другую реализацию, потому что для private-метода нет отношения переопределения.

class Base {
    void call() {
        secret();
    }

    private void secret() {
        System.out.println("Base");
    }
}

class Child extends Base {
    void secret() {
        System.out.println("Child");
    }
}

class Demo {
    public static void main(String[] args) {
        Base value = new Child();
        value.call();
        ((Child) value).secret();
    }
}

Первый вызов печатает Base: метод call связан с закрытым методом Base.secret. Второй вызов печатает Child, поскольку это прямой вызов отдельного метода Child.secret. Если добавить к методу Child.secret аннотацию @Override, код не скомпилируется.

Для настоящей точки расширения можно использовать protected-метод. Это позволяет базовому алгоритму вызывать реализацию наследника, но требует документировать допустимое поведение метода и учитывать, что наследники получают доступ к защищённой части реализации.

Ситуация из практики

В базовом классе обработчика был закрытый метод validate, который вызывался из общего метода process. Команда создала наследника и объявила в нём метод validate с той же сигнатурой, рассчитывая изменить правила проверки, но новые правила не выполнялись в рабочем сценарии.

Рассматривались два варианта. Оставить метод закрытым означало сохранить инкапсуляцию, но не дать наследникам переопределять проверку. Сделать его protected позволяло расширение, однако создавало наследникам зависимость от внутреннего алгоритма базового класса. Передать валидатор через конструктор сохраняло более слабую связанность, но требовало изменить создание объектов и структуру зависимостей.

Выбрали явную стратегию: проверка стала отдельной зависимостью, передаваемой в обработчик. Это не только устранило ошибочное ожидание переопределения, но и позволило тестировать правила независимо от иерархии классов. Если бы наследование было обязательной частью дизайна, альтернативой был бы документированный protected-шаблонный метод.

Что кандидаты часто упускают

Что произойдёт, если закрытый метод базового класса и одноимённый метод наследника имеют разные модификаторы доступа?

Они всё равно остаются независимыми методами, если метод базового класса был private. Нельзя считать метод наследника переопределением только потому, что он объявлен как protected, public или с доступом по умолчанию.

Можно ли вызвать закрытый метод базового класса из метода наследника через super?

Нет. super позволяет обратиться к унаследованным членам и к реализации переопределяемых методов базового класса, но закрытый метод не является доступным членом наследника. Для вызова закрытого метода базовый класс должен сам предоставить доступный метод-обёртку или другую явно предусмотренную операцию.

Почему изменение private на protected может быть не лучшим исправлением?

protected превращает внутреннюю деталь в контракт для наследников: они получают возможность зависеть от метода и переопределять его поведение. Это усиливает связанность и может нарушить инварианты базового класса. Если вариативность не должна задаваться наследованием, лучше передать стратегию, функцию или другой объект-зависимость через конструктор либо метод.