Sollte ich meinen abstrakten Klassen ein "Abstract" -Präfix hinzufügen? [geschlossen]

Angenommen, ich habe eine abstrakte Klasse mit dem Namen Task.

Gibt es einen Standard oder eine Konvention, nach der ich ihn AbstractTaskstattdessen benennen sollte ?

Gemäß Blochs Effective Java (Punkt 18) ist das Abstract-Präfix eine Konvention, die in einem speziellen Fall verwendet wird.

Sie können die Vorzüge von Schnittstellen und abstrakten Klassen kombinieren, indem Sie eine abstrakte Skelettimplementierungsklasse für jede nicht-triviale Schnittstelle bereitstellen, die Sie exportieren. ... Konventionell werden Skelettimplementierungen als AbstractInterface bezeichnet, wobei Interface der Name der von ihnen implementierten Schnittstelle ist.

Bloch weist aber auch darauf hin, dass der Name SkeletalInterface Sinn gemacht hätte, schließt aber daraus

Die abstrakte Konvention ist nun fest etabliert.

Wie andere Antworten gezeigt haben, gibt es im Allgemeinen keinen Grund, diese Namenskonvention auf alle abstrakten Klassen anzuwenden.

Es gibt keine Konvention. Es geht darum, was Ihnen als Entwickler dabei helfen wird, Code schneller und besser zu erstellen und anderen zu helfen, Ihren Code zu verstehen.

Fragen Sie die Leute, die den Code sehen und warten werden. Was würden sie lieber sehen? Was wird es ihnen leichter machen? Nennen Sie es dann basierend auf dem, was sie möchten.

In einem anderen Hinweis, Code-Konventionen für die Java-Programmiersprache: 9. Namenskonventionen erfordern keine:

Klassennamen sollten Substantive sein, wobei der erste Buchstabe jedes internen Wortes groß geschrieben wird. Versuchen Sie, Ihre Klassennamen einfach und aussagekräftig zu halten. Verwenden Sie ganze Wörter - vermeiden Sie Akronyme und Abkürzungen (es sei denn, die Abkürzung wird viel häufiger verwendet als die Langform wie URL oder HTML).

Intellisense wird mir trivialerweise mitteilen, ob es abstrakt ist, also verletzen Sie hier nur DRY.

Dies ist etwas eine Frage der Präferenz (aber grenzwertig schlechte Praxis), aber die meisten Leute mögen es nicht, einen Teil der Qualifikanten im Namen der Klasse zu sehen.

Die meisten IDEs stellen diese Informationen sowieso problemlos zur Verfügung, sodass es nicht erforderlich ist, sie in den Namen einzufügen, und es ist sauberer, sie einfach wegzulassen. Es erinnert an die ungarische Notation für Variablennamen, und das wird heutzutage sicherlich als schlechte Form angesehen. Ich empfehle es einfach anzurufen Task.

In .NET wird häufig die Verwendung von "Base" als Suffix zur Bezeichnung einer abstrakten Basisklasse verwendet. Ich würde auf die anderen Antworten zurückgreifen, ob dies in Java üblich ist.

Meiner Meinung nach sollte der Name einer Entität keine Informationen über ihre Typstruktur vermitteln, sondern über ihre Semantik. Es ist daher nicht sinnvoll, Ihre Klasse als "AbstractSomething" zu definieren, wenn die Abstraktion nicht Teil ihres Laufzeitziels ist. Dass es sich um eine abstrakte Basisklasse handelt, ist für den Programmierer sichtbar und muss sich nicht im Namen widerspiegeln.

Wenn es jedoch perfekt ist, eine Implementierung einer abstrakten Factory als AbstractFactory zu bezeichnen, hängt dies mit der Absicht der Klasse zusammen.

Bevorzugen Sie im Allgemeinen Namenskonventionen, mit denen Sie die meisten Informationen über das Ziel Ihrer Klasse übermitteln können.

Ebenso fern bleiben von SomethingImpl. Es ist uns egal, dass es sich um eine Implementierung und nicht um eine Basisklasse handelt. Wenn Ihre Klassenhierarchie ordnungsgemäß für die Vererbung ausgelegt ist, kann jemand davon erben. Sicherlich würde es keinen Wert geben, wenn sie mehr "Impl" -Suffixe oder andere Artefakte hinzufügen würden. Es ist auch nicht sinnvoll, ein Suffix "Schnittstelle" oder ein Präfix "I" hinzuzufügen.

Erwägen:

IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl

Im Gegensatz zu:

Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
                                   <-- Ferrari
                                   <-- Trabi

Ich bevorzuge das letztere bei weitem.

Dies ähnelt in gewisser Hinsicht dem offensichtlichen Missbrauch der Ungarischen Notation , die letztere ihren schlechten Ruf gab , da die Leute fälschlicherweise damit begannen, sie dahingehend zu interpretieren, dass Entwickler ihren Variablen einen Indikator des Variablentyps voranstellen müssen. Obwohl dies manchmal nützlich sein kann (meistens, wenn Sie die Definition des Typs nicht genau nachschlagen können), ist es meistens nutzlos. Simonyis ursprüngliche Idee mit der ungarischen Notation war es, sie als Mnemonik zu verwenden, um den Entwickler an die Fähigkeiten der Entität zu erinnern, nicht an ihren Typ.

Eine gute Faustregel ist, keine Eigenschaften in einen Namen aufzunehmen, die sich aus der Syntax ergeben. Da Sie in Java eine abstrakte Klasse mit dem passenden abstractSchlüsselwort kennzeichnen müssen , würde ich es nicht in den Namen aufnehmen. In C ++ ist der Fall zum Beispiel nicht so eindeutig, aber zumindest der Compiler wird Ihnen mitteilen, wenn Sie eine abstrakte Klasse falsch verwendet haben. In so etwas wie Python ist es keine schlechte Idee, eine abstrakte Klasse explizit als solche zu bezeichnen.

Die übliche Ausnahme von der Regel ist, wenn der Name nicht eindeutig ist. Wenn es aus irgendeinem Grund eine konkrete Unterklasse gibt Task(in anderen Beispielen mag dies sinnvoller sein, aber was auch immer), verwenden Sie diese AbstractTask.

protected abstract SomeClass { }

Dies sagt mir, dass dies eine abstrakte Klasse ist. Das Hinzufügen eines Präfixes ist eine Tautologie und ein Anti-Pattern und in den meisten Fällen nicht angebracht. Sehen Sie sich den Link an, in dem es beispielsweise darum geht package local, eine Ausnahme zu sein.

In den meisten Fällen AbstractKlassen sollten nicht Teil einer öffentlich zugänglichen API sein, wenn es wirklich ein guter Grund ist da und ein guter Grund sein sollte , sollte eine offensichtlich gute anderen Namen als bieten AbstractSomeClass.

In den meisten Fällen, in denen Sie keinen aussagekräftigeren Namen finden können, müssen Sie wahrscheinlich eine Neugestaltung vornehmen.

Meine fünf Cent, wahrscheinlich haben Sie Implementierungen dieser abstrakten Klasse und sie werden 'SomeSpecificTask', 'TaskWithBubbles', 'StrangeTask' usw. heißen. Es wird also keinen Namenskonflikt zwischen Ihrer abstrakten 'Task' und ihnen geben.

Darüber hinaus handelt es sich bei "abstrakten" Wörtern um Sprachsyntax und nicht um Geschäftsdomänenentitäten. Daher würde ich es vorziehen, sie nicht als Teil des Namens zu verwenden.

Auf der anderen Seite habe ich in einer Antwort hier einen Auszug aus J.Bloch Effective Java gesehen, der besagt, dass die Verwendung von 'abstract' als Teil eines Namens eine etablierte Praxis ist. Es kann so sein. Aber in offiziellen Java-Code-Konventionen gibt es sowieso nichts darüber.

Wenn Sie in einem Team arbeiten, muss das gesamte Team entscheiden, ob Sie abstrakten Klassen "Abstract" voranstellen sollen.

Wenn Sie alleine arbeiten, liegt es ganz bei Ihnen, nicht bei mir oder sonst jemandem auf dieser Site.

Ich bin kein Java-Entwickler (INAJD?) Und kenne die Standard-Nomenklatur für solche Dinge nicht, aber ich denke, das Taskhört sich abstrakt genug an, um so wie es ist für sich zu stehen.

Was ist, wenn Sie eine abstrakte AbstractSyntaxTreeKlasse schreiben möchten ? Oder vielleicht nur eine Zusammenfassung SyntaxTree?

Es ist nicht konventionell und kann Menschen leicht verwirren.

Ich hab's gemacht. Ich habe meiner abstrakten Klasse 'AbstractOperation' das Präfix 'Abstract' hinzugefügt. Der Grund, warum ich das getan habe, war, dass es ein anderes Paket gab, das eine nicht abstrakte Klasse namens Operation hatte, und das meinem Team und den später übernommenen Programmierern half, Verwechslungen zwischen den beiden zu vermeiden.