Wie man Interfaces, abstrakte Klassen und ihre Implementierungen benennt

Die Benennung abstrakter Typen und ihrer Implementierungen ist eine Herausforderung. Erfahren Sie, warum Sie Namen wie IRepository, RepositoryImpl und AbstractRepository vermeiden sollten.

Benennen ist schwer, abstrakte Typen zu benennen ist noch schwerer

Wie man so schön sagt, ist die Namensgebung eines der wenigen wirklich schwierigen Probleme beim Programmieren. Wenn es Ihnen so geht wie mir, sitzen Sie wahrscheinlich jeden Tag hinter Ihrem Schreibtisch und zerbrechen sich den Kopf, um einen passenden Namen zu finden.

Dieses Mal möchte ich mich mit einem Problem befassen, das mir immer wieder begegnet: schlecht benannte abstrakte Typen und ihre Implementierungen (Schnittstelle/abstrakte Klasse). Wahrscheinlich haben Sie selbst schon einmal eines dieser problematischen Beispiele erlebt:

• IRepository,
• AbstractRepository oder
• RepositoryImpl's

Wir können und sollten es besser machen. Diese Art der Namensgebung ist in der Regel ein Symptom für eine dieser beiden Ursachen:

1. Eine unnötige Abstraktion
2. Nichtssagende Namensgebung

Lassen Sie uns sehen, was das Problem mit dieser Art der Benennung ist und, was noch wichtiger ist, was Sie dagegen tun können.

Denken Sie nach: Welchen Zweck hat die Abstraktion?

Erstens gibt es den Fall der unnötigen Abstraktion. Einige Programmierer treiben die Idee der "Abstraktion" zu weit und stellen Schnittstellen vor fast alles. Diese neigen dazu, einen Zweck zu verfehlen oder ein zukünftiges Szenario vorwegzunehmen, das möglicherweise nicht eintritt, ein klarer Verstoß gegen das YAGNI-Prinzip. Die Einführung von Abstraktionen sollte immer mit Bedacht erfolgen.

Softwareentwicklung ist ein heikler Balanceakt, bei dem Entscheidungen gerechtfertigt sein müssen. Wie ich bereits erwähnt habe, bedeuten Schnittstellen immer, dass Sie durch die Hinzufügung von Umwegen eine zusätzliche kognitive Belastung in Kauf nehmen müssen. Es sollte immer einen positiven Effekt geben, der diese Kosten ausgleicht.

Wenn Sie das nächste Mal eine IService und ServiceImpl sehen (oder schreiben), denken Sie an den Zweck der Abstraktion. Sie brauchen sie vielleicht nicht!

Denken Sie noch einmal nach: Denken Sie sich einen besseren Namen aus

Zweitens könnte dieses Benennungsmuster auf eine faule Benennung zurückzuführen sein. Benennen ist immer schwierig, und der Weg des geringsten Widerstands - das Gehirn liebt es, faul zu sein - besteht darin, etwas als erstes zu benennen, das einem in den Sinn kommt.

Das Problem ist, dass dies selten das Beste ist, was uns einfällt. Wenn Sie tiefer graben und sich mehr Mühe geben, werden Sie einen besseren Namen finden. In Zukunft werden Sie dafür dankbar sein.

Sie könnten zum Beispiel auf die Kombination Repository/RepositoryImpl stoßen. Was sagt Ihnen das?

Sehr wenig. Er vermittelt lediglich, dass RepositoryImpl ein abstraktes Konstrukt Repository implementiert. Entscheidend ist, dass diese Namen nichts darüber aussagen, was den Implementierer von anderen unterscheidet. Wenn ich mir nur den Klassennamen ansehe, habe ich keine Ahnung, was sie tut. Schreibt sie in eine Datei? In eine Datenbank? In den Speicher? Derzeit müssten Sie sich die Implementierung ansehen, um das herauszufinden, was schlecht ist.

Die Lösung ist einfach: Benennen Sie den Implementierer nach dem, was ihn einzigartig macht. Ein Name wie InMemoryRepository, oder FileRepository sagt mir auf den ersten Blick viel mehr.

Aus den Schützengräben ️

Schauen wir uns ein Beispiel aus der Praxis an, in diesem Fall die Java-API für Sammlungen. Zur Erinnerung: Sie sieht wie folgt aus:

 

Abbildung 1. Java Collections API, von Ramlmn, CC BY-SA 4.0, via Wikimedia Commons

Sehen Sie eine ISets oder ListImpls in dieser Hierarchie?

Nein. Alle Schnittstellen (gelb) haben aussagekräftige Namen wie Set, List oder Queue. Alle Klassen (violett), die sie implementieren, tragen relevante Informationen in ihrem Namen. Ein TreeSet, LinkedList oder PriorityQueue sagt Ihnen sofort, was Sie von ihnen erwarten können.

Einige von Ihnen werden vielleicht auf die abstrakten Klassen (blau) in dieser Hierarchie hinweisen, wie z.B. AbstractQueue. Dafür gibt es einen Grund, aber es ist eine Ausnahme von der Regel.

Ausnahmen von der Regel?

In manchen Situationen können Sie Ihrem abstrakten Typ ein Präfix voranstellen, aber das sollte Ihr letzter Ausweg sein. Sie können nützlich sein in:

• Skelettimplementierungen von abstrakten Typen. Die AbstractQueue ist ein hervorragendes Beispiel dafür. Sie implementiert eine Schnittstelle (Queue), bietet aber die Grundausstattung für die Implementierung einer neuen Art von Warteschlange. Es handelt sich also um eine Skelett-Implementierungsklasse. In solchen Situationen kann man sich keinen besseren Namen ausdenken, denn das ist ihr einziger Zweck, und die Schnittstelle heißt bereits . Laut Effective Java ist das Präfix abstract in diesem Fall zur Konvention geworden, aber andere Namen wie SkeletalQueue wären vielleicht optimaler gewesen.
• Bibliotheken und technische Einschränkungen. Wenn Sie zum Beispiel eine Bibliothek wie Immutables verwenden, haben Sie am Ende einen abstrakten Typ und einen konkreten Typ für jede Sache, die Sie darstellen möchten. Beide Typen bedeuten dasselbe, aber die Namen müssen eindeutig sein, so dass Sie am Ende Typen wie Queue und QueueImpl haben.

Denken Sie daran, dass dies die Ausnahme von der Regel sein sollte. Denken Sie immer gut nach, bevor Sie Ihre abstrakten Typen auf diese Weise prä- oder postfixieren. In den meisten Fällen gibt es bessere Optionen.

Fazit

Schnittstellen und abstrakte Klassen sind wichtige Werkzeuge für die Erstellung von Abstraktionen im Code. Die ausdrucksstarke Benennung abstrakter Typen ist anspruchsvoll, und wenn Sie dies nicht tun, wird die wahre Bedeutung der Typen vor dem Leser verborgen. Überlegen Sie außerdem genau, ob der abstrakte Typ notwendig ist. Manchmal können Sie auch ohne ihn auskommen.

Das Gegenmittel ist einfach, aber nicht leicht: Halten Sie inne und denken Sie nach. Seien Sie nett zu den zukünftigen Lesern Ihres Codes und benennen Sie Schnittstellen und abstrakte Klassen absichtlich. Sie werden Ihnen dafür dankbar sein.

Was ist Ihre Meinung? Welche Art der Benennung dieser Typen bevorzugen Sie, und warum?