Изменить модификатор доступа переопределенного метода в Java?

Есть ли причина, по которой можно изменить модификатор доступа переопределенного метода? Например,

abstract class Foo{
    void start(){...}
}

И затем измените модификатор доступа к частному доступу на public,

final class Bar extends Foo{
    @Override
    public void start(){...}
}

Я просто задаю этот вопрос из любопытства.

Ответы

Ответ 1

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

Программы, которые пишут люди, и ситуации, возникающие при программировании, настолько разнообразны, что разработчикам языков лучше не "вторгаться" в то, что программисты могут захотеть сделать с их языком. Если нет веской причины, по которой программист не должен иметь возможности сделать ограничители доступа менее ограничительными в подклассе (например), то лучше оставить это решение программисту. Они знают специфику своей индивидуальной ситуации, но разработчик языка этого не делает. Поэтому я думаю, что это был хороший вызов дизайнеров Java.

Ответ 2

Существует только одно, вы можете захотеть, чтобы переопределение было видимым для большего количества классов, так как модификатор не используется по умолчанию, public расширяет его.

Ответ 3

Расширение класса означает, что подкласс должен по крайней мере предлагать те же функции другим классам.

Если он расширяет это, то это не проблема.

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

Ответ 4

Объяснение таково: -

Это фундаментальный принцип в ООП: дочерний класс является полноправным экземпляром родительского классa > и поэтому должен содержать по крайней мере тот же интерфейс, что и родительский класс. > Снижение видимости защищенных/общественных вещей нарушит эту идею; вы можете сделать дочерние > классы непригодными для использования в качестве экземпляров родительского класса.

 class Person{
 public void display(){
  //some operation
 }
 }

class Employee extends Person{
private void display(){
   //some operation
 }


 Person p=new Employee();

Здесь p - ссылка на объект с типом Person (суперкласс), когда мы вызываем > p.display(), поскольку модификатор доступа более ограничивает объект ссылка p не может получить доступ к дочернему объекту типа Employee

Ответ 5

Изменить: Хорошо, я изменил свой ответ, чтобы исправить эту проблему.

Если это не удалось сделать, тогда будут случаи, когда класс не сможет реализовать итератор и расширить класс, потому что они имеют один и тот же метод с различными модификаторами доступа.

public Interface A {
  public void method();
}

public abstract classs B {
  protected void method();
}

public class AB extends B implements A {
  /*
   * This would't be possible if the access modifier coulnd't be changed
   * to less restrictive
  */
  public void method();
}