sollte ich alle meine abstrakten Klassen nennen AbstractFoo

Question

Ist es gute Praxis, um sicherzustellen, dass alle abstrakten Klassen Namen mit dem Präfix "Abstract" haben?

Answer 1

Sie können, aber ich tendiere dazu nicht, da es ein Implementierungsdetail ist.

Ich mag es nicht, Implementierungsdetailinformationen in den Namen von Typen und Bezeichnern hinzuzufügen, da sich diese Art von Information in der Zukunft ändern kann. Meiner Meinung nach ist es am besten, Dinge zu benennen, was sie sind, und nicht, wie sie umgesetzt werden.

Answer 2

Das hängt von Ihren Kodierungskonventionen ab.

Sie könnten sie auch FooBase oder nur Foo nennen, wenn Sie nicht bereits über eine Schnittstelle Foo verfügen.

Answer 3

Wenn Sie überlegen, wie es im .NET-Framework ist, nein. Nehmen Sie zum Beispiel die abstrakte Stream-Klasse. Nichts in dem Klassennamen zeigt an, dass es tatsächlich abstrakt ist.

Answer 4

Ich finde es nützlich, Klassen auf diese Weise zu benennen. Es sendet eine Nachricht, dass sie unterklassifiziert werden sollen; nicht instanziiert; enthalten Code, der für Unterklassen usw. gemeinsam ist.

Es ist jedoch nicht immer notwendig. Die meisten Programmierer würden wahrscheinlich "Shape" als eine abstrakte Klasse und "Square", "Circle" usw. als konkret identifizieren. Aber wenn es nicht sofort klar ist, ist es ein nützlicher Hinweis.

Sie sollten sich auch an lokale Programmierkonventionen und Styleguides halten.

Answer 5

Ich denke, es hängt teilweise davon ab, wie Sie die Klasse verwenden werden. Wenn es nur für den internen Gebrauch gedacht ist, um abgeleitete Klassen dazu zu zwingen, einer Schnittstelle zu entsprechen, dann ist das Hinzufügen von Abstract vorher keine schlechte Idee. Wenn Sie jedoch eine Foo-Factory bereitstellen, die Foo-Instanzen bereitstellt, die eigentlich SpecializedFoo1 oder SpecializedFoo2 sind, scheint es schwierig, AbstractFoo-Instanzen zurückzugeben.

Answer 6

Ich denke, diese Namenskonvention wird nur verwendet, weil es schwierig ist, einen anderen guten Namen zu finden. Wenn Sie bereits eine Schnittstelle namens "List" haben, wie würde man die "AbstractList" -Klasse nennen? Es geht mehr darum, Namenskonflikte zu vermeiden und Implementierungsdetails zu nennen.

Answer 7

Ein bisschen schwer zu erklären, aber ich benutze es nur, um zu vermeiden, kopieren Sie den gleichen Code in funktionalen Klassen und nicht in so etwas wie Domain-Objekte.

• AbstractServiceTestCase -> Die Zusammenfassung Präfix scheint hilfreich
• AbstractAnimal -> scheint seltsam und wenig hilfreich

Sie natürlich für sich selbst entscheiden sollte, solange die gleiche Konvention während eines Projekts folgt .

Answer 8

Die Antworten sind bisher sehr hilfreich und zeigen eine verantwortungsvolle Verbreitung der Praxis. Ich stimme tendenziell zu, dass Namen keine Implementierung anzeigen sollten (Foo könnte eine abstrakte Klasse sein, die später in eine Schnittstelle verschoben wurde). Allerdings ist es für mich beim Codieren nützlich, visuelle Hinweise zu haben, dass ich Methoden für abgeleitete Klassen bereitstellen muss.

Als Beispiel habe ich derzeit eine Hierarchie (fragen Sie nicht nach den Gründen für die Namen, aber sie sind sinnvoll im Kontext und bilden XML-Elementnamen ab).Ich bin mit Java, aber ich denke, die meisten Sprachen wäre ähnlich:

public abstract class Marker {...} 
public class TemplateMarker extends Marker {...} 
public class RegexMarker extends Marker {...} 

statt

public abstract class AbstractMarker {...} 
public class Template extends AbstractMarker {...} 
public class Regex extends AbstractMarker {...} 

oder

public abstract class AbstractMarker {...} 
public class TemplateMarker extends AbstractMarker {...} 
public class RegexMarker extends AbstractMarker {...} 

:

public abstract class Marker {...} 
public class Template extends Marker {...} 
public class Regex extends Marker {...} 

ich jetzt auf mich dazu neigt,

Ich kann mich persönlich daran erinnern, dass Marker ist ein abstraktes funktionales Konzept und die Unterklassen sind konkrete Implementierungen.

Answer 9

Ich würde nicht abstrakte Klassen Zusammenfassung aus dem folgenden Grunde nennen:

Jeden Rectangle ist eine Form. Überall wo Sie eine Form verwenden können, können Sie ein Rechteck verwenden. Code, der mit einem Rechteck beschäftigt (die aber auch mit Kreisen umgehen kann) könnte wie folgt aussehen:

Shape s = .....; 
s.drawTo(myGraphicsContext); 

ein Objekt (zB ein Rechteck) überall eine Verallgemeinerung davon verwenden kann (zB Shape) ist ein wichtige Teil des objektorientierten Konzepts und bekannt als Liskov Substitution Principle. (Es ist auch offensichtlich: Welche Art von Satz oder Logik würde Aussagen über Formen machen, aber dann nicht auf Rechtecke anwendbar sein?)

Wenn Sie die Generalisierung ein AbstractShape nennen, wird dieses Prinzip verletzt. Ein Rechteck ist keine AbstractShape. Wenn überhaupt, ist es eine "Betonform"! Ein Rechteck ist nicht abstrakt (im Sinne von "Ich weiß nicht, welche Art von Form das ist. Könnte ein Rechteck sein, könnte alles andere sein."). Code mit AbstractShape liest dann falsch:

AbstractShape s = new Rectangle(...); 

ich mit mehr Gedanken zu diesem Thema here gebloggt.