2012-02-17 12 views
15

Czy istnieje powód, dla którego można zmienić modyfikator dostępu zastąpionej metody? Na przykład,Zmienić modyfikator dostępu nadpisanej metody w Javie?

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

a następnie zmienić modyfikatora dostępu pakiet-prywatnego do public,

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

Tylko pytam to pytanie z ciekawości.

+1

możliwe duplikat [modyfikatorów dostępu Java i metod nadrzędnych] (http://stackoverflow.com/questions/6851612/java-access-modyfikatory-i-overriding-metody) –

Odpowiedz

17

Java nie pozwala uczynić modyfikatora dostępu bardziej restrykcyjnym, ponieważ naruszałoby to zasadę, że instancja podklasy powinna być użyteczna w miejsce instancji nadklasy. Ale jeśli chodzi o ograniczanie dostępu, to być może superklasa została napisana przez inną osobę i nie przewidywała sposobu, w jaki chcesz używać swojej klasy.

Programy pisane przez użytkowników i sytuacje pojawiające się podczas programowania są tak różnorodne, że dla projektantów języka lepiej jest "nie zgadywać", co programiści mogą chcieć zrobić z ich językiem. Jeśli nie ma uzasadnionego powodu, dla którego programista powinien: , a nie być w stanie uczynić specyfikatory dostępu mniej restrykcyjnymi w podklasie (na przykład), to lepiej pozostawić tę decyzję programistom. Zna specyfikę ich indywidualnej sytuacji, ale projektant języka tego nie robi. Więc myślę, że to było dobre zaproszenie dla projektantów Javy.

6

Jest tylko jeden, możesz chcieć, aby przesłonięcie było widoczne przez więcej klas, ponieważ żaden modyfikator nie jest domyślny, publiczny rozszerza to.

+0

Tak, to była jedyna korzyść, jaką mogłem zobaczyć ... Nie wiedziałem, czy było w tym coś więcej. – mre

1

Edycja: OK, zmieniłem odpowiedź, aby rozwiązać problem.

Jeśli nie można tego zrobić, to w niektórych przypadkach klasa nie będzie w stanie zaimplementować iterface i rozszerzyć klasy, ponieważ mają tę samą metodę z różnymi modyfikatorami dostępu.

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

Wszystkie metody zdefiniowane w interfejsie są niejawnie publiczne. – GriffeyDog

+1

Wszystkie metody interfejsów muszą być publiczne. – Puce

+0

Nie możesz mieć deklaracji metody nie-łonowej w interfejsie publicznym lub chronionym (Bóg tylko wie, co znaczy chroniony interfejs). http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html Patrz sekcja 9.1.4 – Dunes

6

Rozszerzenie klasy oznacza, że ​​podklasa powinna przynajmniej oferować tę samą funkcjonalność innym klasom.

Jeśli to rozszerzy, to nie będzie problemu.

Rozszerzaniem może być dodawanie nowych metod lub oferowanie istniejących metod do większej liczby klas, np. Upublicznianie metody dostępu do pakietu.

2

wyjaśnieniu to: -

Jest to fundamentalna zasada w OOP: klasa dziecko jest pełnoprawnym instancja> klasy nadrzędnej, a zatem musi występować co najmniej taki sam interfejs jak rodzica klasa. > Robienie rzeczy chronionych/publicznych mniej widocznych naruszyłoby ten pomysł; można uczynić klasy> dziecko niezdatnymi do użytku jako wystąpienia klasy nadrzędnej.

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

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


Person p=new Employee(); 

Tutaj p jest odwołanie do obiektu z klasy typu osoby (Super), kiedy dzwonisz> P.wyświetlacz() jako modyfikator dostępu jest bardziej restrykcyjne Przedmiotem odniesienia P, nie może uzyskać dostępu do obiektu potomnego typu pracownika

Powiązane problemy