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

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

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

а затем измените модификатор package-private access на public,

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

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

16
access-modifiers java method-overriding

5 ответов

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

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

18

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

6

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

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

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

6

объяснение это:-

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

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

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


 Person p=new Employee();

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

2

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

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

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();
}
1