2015-08-10 17 views
5

Gemäß Abschnitt „8.1.1.1“ von JLS haben wir:Vererbung von abstrakten Methoden mit Paketzugriffs

Eine Klasse C hat abstrakte Methoden, wenn eine der folgenden Bedingungen zutrifft:

• Jede der Mitglieds Methoden (§8.2) von C - entweder deklariert oder geerbt - ist abstract.

• Jede von Oberklassen der C eine abstrakte Methode mit Paketzugriffs erklärt hat, und es gibt keine Methode, die die abstrakte Methode aus C oder aus einer Oberklasse von C

Es ist interessant, außer Kraft setzt, warum haben wir zweite Option hier. Vor allem, warum haben wir genau "Paketzugang". Und was ist mit "öffentlichen" oder "geschützten" Methoden?

+0

Es ist im Grunde gesagt, dass Ihre Klasse abstrakt ist, bis Sie konkrete Implementierungen für alle Ihre abstrakten Methoden bereitstellen (Methoden explizit in Ihrer Klasse oder implizit von übergeordneten Klassen). Denken Sie daran: "Paketumfang" ist, wenn Sie * nicht "öffentlich" oder "geschützt" oder "privat" angeben; Es ist überall in der Verpackung sichtbar und außerhalb der Verpackung nicht sichtbar. – paulsm4

Antwort

3

Von der Bestellung der meisten privaten offenste, die Java-Modifikatoren gehen:

  • Privat
  • Paket
  • geschützt
  • öffentlichen

Child-Klassen können die Paket Methoden nicht erben einer Elternklasse in einem anderen Paket. Eine Klasse, die von einem solchen Elternteil erbt, wäre also gemäß Regel 1 nicht abstrakt. Daher existiert die zweite Regel, um die Situation zu behandeln, in der eine Kindklasse von einem abstrakten Elternteil erbt und keine Implementierung der abstrakten Paketmethoden bereitstellen kann.

Es ist eine unsinnige Situation, und ich würde nie erwarten, dies in irgendeinem Programm irgendwo zu sehen. Die Sprache muss jedoch vollständig angegeben werden, sonst könnte ein seltsamer Fehler auftreten, der die Instanziierung einer Klasse mit nicht definierten Methoden ermöglicht.

0

Die wahrscheinlichste Bedeutung davon ist, dass protected und public auch Deklarationen sind, die den Paketzugang bereitstellen. private Methoden sind nicht, und sie können auch nicht abstrakt sein.

0

Ja, ich denke, Sie haben Recht. Die zweite Option betrifft nur einen bestimmten Fall: besondere Unterklasse ist in einem anderen Paket als seine Oberklasse.

Zum Beispiel

package superpackage; 

public abstract class SuperFoo { 
    abstract void foo(); 
} 


package subpackage; 

import superpackage.SuperFoo; 

public abstract class SubFoo extends SuperFoo {} 

Bitte beachten Sie, dass diese Klasse abstrakt deklariert werden sollte, sonst Kompilierungsfehler wir haben.

In diesem speziellen Fall haben wir nicht "Vererbung von foo-Methode" als Vererbung erfordert , dass SubFoo-Klasse im gleichen Paket wie SuperFoo sein. siehe Abschnitt 8.4.8 in JLS für weitere Details.

Trotzdem enthält diese Klasse immer noch die "foo" -Methode (per Definition) und sollte daher mit abstract keyword markiert werden.

Außerdem können wir unsere SubFoo-Klasse um eine weitere konkrete Klasse erweitern, die zum "Superpackage" -Paket gehört.

Zum Beispiel

package subclass; 

import subpackage.SubFoo; 

public class SecondSubFoo extends SubFoo { 
    @Override 
    void foo() {} 
} 

Hinweis:

1) Die Tatsache, dass die öffentlichen und geschützten Methoden in Artikel der Definition zuerst fallen, wie sie vererbt werden und es besteht keine Notwendigkeit zweite Element der Definition für Sie.

2) Paketzugriffsmethoden fallen auch in das erste Element der Definition, wenn sie sich im selben Paket befinden und daher gibt es kein zweites Element der Definition für sie auch.

3) Andererseits fallen Paketzugriffsmethoden, die in dem anderen Paket enthalten sind, nicht in den ersten Definitionsbereich, da sie nicht vererbt werden (siehe Definition der Vererbung abstrakter Methoden in Abschnitt 8.4.8 von JSL). und daher sind sie ein zweiter Definitionsgegenstand.

Verwandte Themen