Gibt es in Java ein Idiom für leere Methoden, die existieren, um eine Schnittstelle zu erfüllen?

Question

Nehmen wir an, ich habe eine Klasse Foo mit einer Schnittstelle wie MouseListener implementieren. Die MouseListener Schnittstelle besteht aus fünf Methoden, aber ich möchte nur eine von ihnen überschreiben (mouseClicked()). Gibt es eine standardmäßige, idiomatische Formatierung der anderen Methoden?

Meine Neigung war folgendes zu schreiben:

@Override 
public void mouseClicked(MouseEvent e) { 
    // (...) <-- actual code here 
} 

@Override 
public void mouseEntered(MouseEvent e) { 
    // Do nothing. Exists to satisfy MouseListener interface. 
} 

@Override 
public void mouseExited(MouseEvent e) { 
    // Do nothing. Exists to satisfy MouseListener interface. 
} 

@Override 
public void mousePressed(MouseEvent e) { 
    // Do nothing. Exists to satisfy MouseListener interface. 
} 

@Override 
public void mouseReleased(MouseEvent e) { 
    // Do nothing. Exists to satisfy MouseListener interface. 
} 

Ich bin ein Fan von so dass es ausdrücklich, dass Methoden sind absichtlich leer und nicht versehentlich nicht so, aber ich bin nicht verrückt nach all den vertikalen Raum für nichts aufgegeben. Ich habe auch das folgende Format zu sehen:

public void mouseClicked(MouseEvent e) { 
    // (...) <-- actual code here 
} 

public void mouseEntered(MouseEvent e) {} 
public void mouseExited(MouseEvent e) {} 
public void mousePressed(MouseEvent e) {} 
public void mouseReleased(MouseEvent e) {} 

Ich bin mit diesem im Allgemeinen OK und ich verstehe die Absicht des Autors, aber es wird wirklich hässlich, wenn die (recommended) @Override Anmerkungen hinzugefügt werden.

Ich bin kein besonders erfahrener Java-Programmierer, also dachte ich, ich würde fragen, ob es eine Konvention gab. Gedanken?

Answer 1

Verwenden Mouseadapter

Answer 2

ich es auf die gleiche Weise tun, wenn Theres nichts da in einer Zeile verlassen. Vielleicht ein Kommentar zu einem großen Block von "Implementierungs-Einzeilern".

Answer 3

MouseAdapter ist ideal für diesen speziellen Fall und das Adapter-Idiom ist im Allgemeinen großartig. Ein Adapter verfügt über leere Implementierungen aller Methoden der Schnittstelle, sodass Sie nur die Methoden ableiten und implementieren können, die für Ihre Klasse relevant sind. Der Adapter könnte alternativ, wie Andrew Hare vorschlägt, NotImplementedException's werfen.

Answer 4

In diesem speziellen Fall sollten Sie den Ratschlägen von wilums2 folgen und MouseAdapter erweitern, anstatt MouseListener zu implementieren. Der Zweck dieser Adapterklassen besteht darin, dass Sie keine leeren Implementierungen bereitstellen müssen, wenn Sie nur einige der Methoden einer Schnittstelle implementieren.

Allgemeiner die kurze Antwort ‚nein‘ lautet, gibt es keine Standard-Konvention, wie leere Methoden zu dokumentieren, obwohl ich in der Regel so etwas wie verwenden

@Override 
void foo() { 
    // No implementation necessary 
} 

Answer 5

Der Zweck eines Zuhörers ist benachrichtigt werden von einige Ereignisse. Wenn die Listener-Schnittstelle mehr Methodenrückrufe enthält als Sie benötigen, ignorieren Sie einfach diejenigen, die Sie nicht interessieren. In Ihrem Fall wurde MouseAdapter für genau diesen Zweck entworfen. Do nicht werfen UnsupportedOperationException wie der Aufrufer höchstwahrscheinlich nicht die Ausnahme erwartet. Es verletzt höchstwahrscheinlich auch den Vertrag der Hörerschnittstelle, da erwartet wird, dass jede Methode implementiert wird.

Answer 6

Ich denke, ich würde es als "No-Op-Implementierungen" beschreiben oder vielleicht den Begriff "Adapter" verwenden. Wie andere bemerkt haben, bietet Java eine MouseAdapter Klasse, die das tut, was Sie wollen. Streng genommen fällt es nicht ganz in die Definition des Adaptermusters, das eine API in eine andere umwandelt, aber ehrlich gesagt, tendiere ich dazu, pragmatisch solche Dinge zu benennen.

Wahrscheinlich ist das Wichtigste, was zu tun ist, dass Sie beabsichtigen, dass die Methode keine Implementierung hat. In dem spezifischen Fall der MouseAdapter, Sie wahrscheinlich nicht um UnsupportedOperationException werfen gehen wollen, aber im Allgemeinen ist es wahrscheinlich ein gutes Signal, dass Sie nicht beabsichtigen, eine Implementierung bereitzustellen.Ein Kommentar im Quellcode (oder besser der Methodendokumentation), um zu erklären, warum Sie die Schnittstelle nicht vollständig implementieren, ist normalerweise notwendig.

Answer 7

Ich glaube nicht, dass es besonders wichtig ist. Für meinen persönlichen Geschmack mag ich nicht neben der Öffnung der schließenden Klammer, um zu sehen, was gibt:

public void mouseEntered(MouseEvent e) { 
} 

Ein bisschen leer, aber okay. Im Falle eines Rückgabewerts können wir es konsistent aussehen lassen, was Sie nicht mit dem [] Stil bekommen.

Aber wenn es in Schleifen zu dem seltenen Fall kommt, wie ich ein Semikolon dort in:

// Made up example. 
while (++i < len && str.charAt(i) != '\0') { 
    ; 
} 

Welche geben würde:

public void mouseEntered(MouseEvent e) { 
    ; 
} 

Im Fall von catch Klauseln, würden Sie besser eine gute Entschuldigung in einem Kommentar (möglicherweise eine Unterbrechung fallen lassend).

Answer 8

Im Allgemeinen handelt es sich um eine Erweiterung des Null-Objektmusters. Sie definieren ein Null-Objekt und erweitern es, indem Sie nur die Methoden außer Kraft setzen, die Ihnen wichtig sind.

Als Beispiel für eine Möglichkeit, dies zu automatisieren, können Sie in meinen JavaDude-Bean-Annotationen (http://code.google.com/p/javadude/wiki/Annotations) Folgendes tun: [HINWEIS: Ich würde dies nicht für MouseListener empfehlen, da der MouseAdapter bereits existiert und Sie ihn einfach unterklassifizieren können ... Das Folgende ist nützlich für andere große Interfaces, wo Sie nur ein paar ausgewählte Methoden implementieren wollen]

@Bean(nullObjectImplementations = @NullObject(type=MouseListener.class)) 
public class MyMouseHandler extends MyMouseHandlerGen { 
    public void mouseClicked(MouseEvent e) { 
     // your handling of a MouseClick 
    } 
} 

Sie können dann MyMouseHandler verwenden den Klick zu behandeln =

. Hinweis: Mouseadapter war ein wirklich schlechte Wahl für den Namen der Klasse in der JRE/JDK. Es ist keine Instanz des GoF-Adaptermusters. es ist wirklich eine Null-Objektimplementierung eines MouseListener.

BTW: Sie können auf der gleichen Linie setzen @Override wie die Methodendeklaration - für Ihr Beispiel Sie

@Override public void mousePressed(MouseEvent e) { /* not needed */ } 
// et al 

Answer 9

haben kann ich diese Zeit fand für diese genaue Frage zu suchen. Ich benutze auf Scroll, wo ich onScrollStateChanged, aber nicht onScroll brauche. Ich lehnte in Richtung:

@Override 
public void onScroll(AbsListView view, int firstVisibleItem, int visibleItemCount, 
      int totalItemCount) { 
    return;   
} 

Allerdings mag ich das zweite Beispiel, das Sie geben (mit Klammern in der gleichen Zeile). Es ist kompakt und sauber und kann konsequent die Idee ausdrücken, dass es absichtlich leer gelassen wird.

Edit: das ist, was ich angesiedelt:

@Override 
public void onScroll(AbsListView view, int firstVisibleItem, int visibleItemCount, 
      int totalItemCount) {return;} 

Dieses viele Parameter hat, so dass es nicht so schön aussieht wie auf einer Linie, aber Sie bekommen die Idee.

Answer 10

Es gibt mehrere Möglichkeiten, dies zu tun. Die Oracle java conventions p6.4 (Seite 11) sagt, die leeren Methoden wie

aussehen sollten

public void empty() {} 

Es gibt auch ein Dokument, das von Steve Yohanan 2003 Ameise geschrieben es sagt

public void empty() 
{ 
} 

Obwohl ich habe keine Konvention für „leer gefunden Methode als Schnittstellen-Stub ". Als Schlussfolgerung gibt es keinen standardisierten Weg, dies zu tun. Manche bevorzugen es, einen Kommentar zu hinterlassen, andere bevorzugen es, eine Zeile zu schreiben, andere schreiben sie wie jede andere Methode mit leerem Text.