Namenskonventionen für abstrakte Klassen

Ich erinnere mich deutlich daran, dass die von Microsoft vorgebrachte Richtlinie einmal darin bestand, einer abstrakten Klasse das Suffix "Base" hinzuzufügen, um die Tatsache zu vermeiden, dass es abstrakt war. Daher haben wir Klassen wie System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBase, und, natürlich, System.Collections.CollectionBase.

Ich habe jedoch festgestellt, dass in letzter Zeit viele abstrakte Klassen im Framework dieser Konvention nicht zu folgen scheinen. Beispielsweise sind die folgenden Klassen alle abstrakt, folgen jedoch nicht dieser Konvention:

• System.DirectoryServices.ActiveDirectory.DirectoryServer

• System.Configuration.ConfigurationElement

• System.Drawing.Brush

• System.Windows.Forms.CommonDialog

Und genau das könnte ich in wenigen Sekunden erreichen. Also habe ich nachgeschlagen, was die offizielle Dokumentation zu sagen hat, um sicherzugehen, dass ich nicht verrückt bin. Ich habe die Namen von Klassen, Strukturen und Schnittstellen in MSDN unter Entwurfsrichtlinien für die Entwicklung von Klassenbibliotheken gefunden . Seltsamerweise kann ich die Richtlinie zum Hinzufügen von "Base" am Ende des Namens einer abstrakten Klasse nicht erwähnen. Die Richtlinien sind für Version 1.1 des Frameworks nicht mehr verfügbar.

Also, verliere ich es? Gab es diese Richtlinie jemals? Wurde es nur wortlos aufgegeben? Habe ich in den letzten zwei Jahren umsonst lange Klassennamen alleine erstellt?

Jemand wirft mir hier einen Knochen.

Update Ich bin nicht verrückt. Die Richtlinie existierte. Krzysztof Cwalina greift 2005 dazu auf.

In den Framework Design Guidelines S. 174 heißt es:

Vermeiden Sie es , Basisklassen mit dem Suffix "Base" zu benennen, wenn die Klasse für die Verwendung in öffentlichen APIs vorgesehen ist.

Außerdem: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx

Wenn die abstrakte Klasse einige statische Elemente enthält, die verwendet werden, kann die 'Basis' hässlich werden.

Ich erinnere mich nicht an eine solche Richtlinie. Ich glaube, Sie sollten die sinnvolle Benennung verwenden. Manchmal ist die abstrakte Klasse nur so konzipiert, dass sie einigen Klassen (als Werkzeug) gemeinsame Funktionen bietet, die meiner Meinung nach das Suffix haben sollten. In einigen Fällen möchten Sie es jedoch als Basis für eine Polymorphismus-Hierarchie verwenden, die selbst nicht vollständig ist. In diesen Fällen schlage ich vor, wie eine normale Klasse zu benennen.

Wie Sie sehen, werden Sie wahrscheinlich keine Methode deklarieren, die eine ButtonBase als Parameter akzeptiert. Es wurde entwickelt, um minimale Funktionen für Unterklassen bereitzustellen. Sie können a jedoch ConfigurationElementals eine Entität behandeln, die unterschiedliche Formen hat, aber für sich selbst nicht vollständig ist (und daher abstrakt ist).

Manchmal ist Base immer noch erforderlich, insbesondere wenn Sie sowohl eine konkrete als auch eine abstrakte Klasse bereitstellen, die von jemandem erweitert werden kann, um eine konkrete Implementierung zu erstellen.
zB Controller und ControllerBase (eigentlich ist Controller auch abstrakt, bietet aber deutlich mehr Funktionen als ControllerBase)

Das Basissuffix ist beim Programmieren gegen eine Schnittstelle hässlich. Ich denke, die Microsoft-Richtlinie, es nicht zu verwenden, gilt, wenn die abstrakte Klasse überwiegend wie eine Schnittstelle verwendet wird. Wahrscheinlich, was sie mit Public API meinen.

Der Punkt ist, dass es Fälle gibt, in denen es keine bessere Alternative zur Verwendung des Basissuffix gibt.

Ich verstehe die Neigung, ein Basis-Suffix zu vermeiden, aber ich verstehe auch die Notwendigkeit eines Suffix. In einem Kommentar zu diesem Artikel wird nun vorgeschlagen , "Typ" als Suffix als zweite Wahl zu verwenden, um keine zu verwenden. Ich halte dies für verwirrend, aber die Idee, dass "ein solches unverbindliches Wort darauf hindeutet, dass es sich um eine unverbindliche Klasse handelt", blieb mir erhalten.

Als Alternative: Ich würde es vorziehen, "Kind" als Suffix zu verwenden, um das Objekt als "von oder zu einer bestimmten Rasse oder Familie gehörend" anzugeben ( Wiktionary: -kind ).

Beispiel: DataProviderund ReflectiveDataProvidersind beidesDataProviderKind

Inspiriert von der Biologie, wo zB "canis lupus" zur Familie "Canoidea" gehört, was sehr grob "dog-ish" bedeutet.

Microsoft gibt an:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces

"✓ BEACHTEN SIE, den Namen abgeleiteter Klassen mit dem Namen der Basisklasse zu beenden. Dies ist sehr gut lesbar und erklärt die Beziehung klar. Einige Beispiele hierfür im Code sind: ArgumentOutOfRangeException, eine Art Ausnahme, und SerializableAttribute, eine Art des Attributs. Es ist jedoch wichtig, bei der Anwendung dieser Richtlinie ein vernünftiges Urteilsvermögen zu verwenden. Beispielsweise ist die Button-Klasse eine Art Control-Ereignis, obwohl Control nicht in ihrem Namen angezeigt wird. "

Im Allgemeinen schließt dies implizit die Verwendung von "Base" im Namen aus.