Может ли переопределяющий метод иметь другой спецификатор доступа, чем в базовом классе?

Можно ослабить ограничение, но не сделать его более строгим:

public abstract class A {
    protected void method();
}

public class B extends A {
    @Override
    public void method(){    // OK
    }
}

public class C extends A {
    @Override
    private void method(){    // not allowed
    }
}

Сделать исходный метод private тоже не получится, так как такой метод не виден в подклассах и, следовательно, не может быть переопределен.

Я бы рекомендовал использовать interfaces для выборочного раскрытия или скрытия метода:

public interface WithMethod {
    // other methods
    void method();
}

public interface WithoutMethod {
    // other methods
    // no 'method()'
}

public abstract class A {
    protected void method();
}

public class B extends A implements WithMethod {
    @Override
    public void method(){
      //TODO
    }
}

public class C extends B implements WithoutMethod {
    // no 'method()'
}

... тогда работайте с инстансами только через интерфейсы.

При переопределении методов вы можете изменить модификатор только на более широкий, а не наоборот. Например, этот код будет действительным:

public abstract class A {

    protected void method();
}

public class B extends A {
    @Override
    public void method() { }
}

Однако, если вы попытаетесь сузить видимость, вы получите ошибку времени компиляции:

public abstract class A {
    protected void method();
}

public class B extends A {
    @Override
    private void method() {}
}

В вашем случае я бы предложил сделать C не реализующим A, поскольку абстракция A подразумевает, что существует незащищенный method():

public class C {
    private void method(){
      //TODO
    }
}

Другой вариант — сделать реализацию method() в C с выдачей RuntimeException:

public class C extends A {

    @Override
    public void method(){
        throw new UnsupportedOperationException("C doesn't support callbacks to method()");
    }
}

То, о чем вы просите, невозможно по очень веским причинам.

принцип подстановки Лисков в основном гласит: класс S является подклассом другого класса T только тогда, когда можно заменить любое вхождение какого-то "Т-объекта" с каким-то "S-объектом" - не замечая.

Если вы допустите, что S сводит общедоступный метод к частному, вы больше не сможете этого делать. Потому что внезапно этот метод, который можно было вызвать при использовании некоторого T ..., больше не доступен для вызова на S.

Короче говоря: наследование — это не то, что просто падает с неба. Это свойство классов, за которое отвечает вы как программист. Другими словами: наследование означает больше, чем просто запись «класс S расширяет T» в вашем исходном коде!

Это невозможно из-за полиморфизма. Рассмотрим следующее. У вас есть метод в классе A с некоторым модификатором доступа, отличным от private. Почему не частный? Потому что если бы он был частным, то ни один другой класс не мог бы даже знать о его существовании. Значит, это должно быть что-то другое, и это что-то должно быть доступно откуда-то.

Теперь давайте предположим, что вы передаете экземпляр класса C куда-то. Но вы заранее преобразовали его в A, и в итоге у вас есть этот код где-то:

void somewhereMethod(A instance) {
    instance.method(); // Ouch! Calling a private method on class C.
}

Хороший пример того, как это сломалось, — QSaveFile в Qt. В отличие от Java, C++ фактически позволяет снизить привилегии доступа. Так они и сделали, запретив метод close(). В итоге они получили подкласс QIODevice, который на самом деле больше не является QIODevice. Если вы передадите указатель на QSaveFile какому-то методу, принимающему QIODevice*, они все равно смогут вызывать close(), поскольку он общедоступен в QIODevice. Они «исправили» это, заставив QSaveFile::close() (приватный) вызывать abort(), поэтому, если вы сделаете что-то подобное, ваша программа немедленно рухнет. Не очень красивое «решение», но лучшего нет. И это просто пример плохого ООП-дизайна. Вот почему Java не позволяет этого.

Изменить

Не то чтобы я упустил из виду, что ваш класс абстрактный, но я также упустил тот факт, что B extends C, а не A. Таким образом, то, что вы хотите сделать, совершенно невозможно. Если метод public в B, он также будет общедоступным во всех подклассах. Единственное, что вы можете сделать, это задокументировать, что его не следует вызывать и, возможно, переопределить его, чтобы он вызывал UnsupportedOperationException. Но это привело бы к тем же проблемам, что и с QSaveFile. Помните, что пользователи вашего класса могут даже не знать, что это экземпляр C, поэтому у них даже не будет возможности прочитать его документацию.

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

Вот часть @Override контракта.

Ответ таков: нет никакой возможности достичь того, что у вас есть.

Уровень доступа не может быть более строгим, чем уровень доступа переопределенного метода. Например: если метод суперкласса объявлен общедоступным, то переопределяющий метод в подклассе не может быть ни закрытым, ни защищенным.

Это проблема не только abstract классов, но и всех классов и методов.

ТЕОРИЯ:

У вас есть определенный порядок модификаторов:

public <- protected <- default-access X<- private

Когда вы переопределяете метод, вы можете увеличить, но не уменьшить уровень модификатора. Например,

public -> []
protected -> [public]
default-access -> [public, default-access]
private -> []

ПРАКТИКА:

В вашем случае вы не можете превратить ??? в какой-либо модификатор, потому что private является самым низким модификатором, а private члены класса не наследуются.