Schnittstellennamen in Java

Question

Die meisten OO-Sprachen präfixieren ihre Schnittstellennamen mit einem großen I, warum macht Java das nicht? Was war der Grund, diese Konvention nicht zu befolgen?

Um zu verdeutlichen, was ich meine: Wenn ich eine Benutzerschnittstelle und eine Benutzerimplementierung haben möchte, hätte ich in Java zwei Möglichkeiten:

1. Klasse = Benutzer, Schnittstelle = BenutzerSchnittstelle
2. Klasse = BenutzerImpl, Schnittstelle = Benutzer

Während in den meisten Sprachen:

Klasse = Benutzer, Schnittstelle = IBenutzer

Jetzt könnte man argumentieren, dass man immer einen aussagekräftigeren Namen für die Benutzerimplementierung wählen könnte und das Problem verschwindet, aber Java drängt auf einen POJO-Ansatz und die meisten IOC-Container verwenden umfangreich DynamicProxies. Diese beiden Dinge zusammen bedeuten, dass Sie viele Schnittstellen mit einer einzigen POJO-Implementierung haben werden.

Also, meine Frage kommt letztlich darauf hinaus: "Ist es sinnvoll, der breiteren Schnittstellennamenskonvention zu folgen, insbesondere angesichts der Richtung, in die Java-Frameworks zu gehen scheinen?"

Answer 1

Bob Lee sagte einmal in einer Präsentation:

was ist der Sinn einer Schnittstelle, wenn Sie nur eine Implementierung haben.

Also beginnen Sie mit einer Implementierung, d.h. ohne eine Schnittstelle. Später entscheiden Sie, na ja, hier besteht Bedarf an einer Schnittstelle, also wandeln Sie Ihre Klasse in eine Schnittstelle um.

Dann wird offensichtlich: Ihre ursprüngliche Klasse hieß User. Ihre Schnittstelle heißt jetzt auch User. Vielleicht haben Sie eine UserProdImpl und eine UserTestImpl. Wenn Sie Ihre Anwendung gut entworfen haben, wird jede Klasse (außer denen, die User instanziieren) unverändert sein und nicht bemerken, dass plötzlich eine Schnittstelle übergeben wird.

also wird es klar -> Schnittstelle User Implementierung UserImpl.

Answer 2

Im C# sieht es so aus

public class AdminForumUser : UserBase, IUser

In Java würde man sagen

public class AdminForumUser extends User implements ForumUserInterface

Aufgrund dessen denke ich nicht, dass Konventionen in Java für Schnittstellen fast so wichtig sind, da es einen expliziten Unterschied zwischen Vererbung und Schnittstelleneinführung gibt. Ich würde einfach eine Namenskonvention wählen, die Ihnen gefällt, solange Sie konsequent sind und etwas verwenden, um den Leuten zu zeigen, dass dies Schnittstellen sind. Ich habe seit ein paar Jahren kein Java mehr gemacht, aber alle Schnittstellen wären einfach in ihrem eigenen Verzeichnis, und das war die Konvention. Hatte damit nie wirklich Probleme.

Answer 3

In meiner Erfahrung gilt die Konvention "I" für Schnittstellen, die dazu bestimmt sind, einen Vertrag für eine Klasse bereitzustellen, insbesondere wenn die Schnittstelle selbst keine abstrakte Vorstellung der Klasse darstellt.

Zum Beispiel würde ich in Ihrem Fall nur IUser erwarten, wenn der einzige Benutzer, den Sie jemals haben wollen, User ist. Wenn Sie verschiedene Arten von Benutzern planen - NoviceUser, ExpertUser, usw. - würde ich erwarten, eine User-Schnittstelle zu sehen (und vielleicht eine AbstractUser-Klasse, die einige gemeinsame Funktionen implementiert, wie get/setName()).

Ich würde auch erwarten, dass Schnittstellen, die Funktionen definieren - Comparable, Iterable, usw. - so benannt sind und nicht wie IComparable oder IIterable.

Answer 4

In Übereinstimmung mit guten OO-Prinzipien sollte Ihr Code (soweit praktisch/möglich) von Abstraktionen abhängen und nicht von konkreten Klassen. Zum Beispiel ist es im Allgemeinen besser, eine Methode wie diese zu schreiben:

public void doSomething(Collection someStuff) {
    ...
}

als diese:

public void doSomething(Vector someStuff) {
    ...
}

Wenn Sie diesem Gedanken folgen, bin ich der Ansicht, dass Ihr Code leichter lesbar ist, wenn Sie Schnittstellen Namen wie "Benutzer" und "Bankkonto" geben (zum Beispiel), anstatt "IUser", "Benutzerschnittstelle" oder andere Variationen.

Die einzigen Codezeilen, die sich um die tatsächlichen konkreten Klassen kümmern sollten, sind die Stellen, an denen die konkreten Klassen erstellt werden. Alles andere sollte unter Verwendung der Schnittstellen geschrieben werden.

Wenn Sie dies tun, sollten die "hässlichen" konkreten Klassennamen wie "UserImpl" sicher vor dem übrigen Code versteckt sein, der fröhlich weiterhin die "schönen" Schnittstellennamen verwenden kann.

Answer 5

\=v= Der Präfix "I" wird auch im Wicket-Framework verwendet, wo ich mich schnell daran gewöhnt habe. Im Allgemeinen begrüße ich jede Konvention, die umständliche Java-Klassennamen verkürzt. Es ist jedoch lästig, dass alles unter "I" in den Verzeichnissen und im Javadoc alphabetisch geordnet ist.

Die Wicket-Codierungspraxis ähnelt der von Swing, da viele Steuerelement-/Widget-Instanzen als anonyme innere Klassen mit Inline-Methodendeclarations erstellt werden. Ärgerlicherweise unterscheidet sie sich um 180° von Swing, da Swing einen Präfix ("J") für die Implementierungsklassen verwendet.

Der Suffix "Impl" ist ein verwirrendes Abkürzung und internationalisiert sich nicht gut. Wenn wir wenigstens mit "Imp" gegangen wären, wäre es niedlicher (und kürzer). "Impl" wird für IOC verwendet, insbesondere Spring, also sind wir vorerst darauf festgelegt. Es wird etwas schizo, wenn man 3 verschiedene Konventionen in drei verschiedenen Teilen einer Codebasis befolgen muss.