dovrei nominare tutte le mie classi astratte AbstractFoo

Question

È buona norma assicurarsi che tutte le classi astratte abbiano nomi preceduti da "Abstract"?

Answer 1

Si può ma io tendo a non farlo poiché si tratta di un dettaglio di implementazione.

Non mi piace aggiungere informazioni dettagliate sull'implementazione nei nomi dei tipi e degli identificatori poiché tale tipo di informazioni potrebbe cambiare in futuro. Secondo me è meglio dare un nome alle cose, non a come vengono implementate.

Answer 2

Dipende dalle convenzioni di codifica.

Si potrebbe anche chiamarli FooBase o semplicemente Foo se non si dispone già di un'interfaccia Foo.

Answer 3

Se si considera come è nel framework .NET, no. Prendi ad esempio la classe Stream astratta. Nulla nel nome della classe indica che è in realtà astratto.

Answer 4

Trovo utile classificare le classi in questo modo. Invia un messaggio che sono destinati ad essere sottoclassificati; non istanziato; contiene codice comune a sottoclassi, ecc.

Non è sempre necessario però. La maggior parte dei programmatori probabilmente identifica "Forma" come una classe astratta e "Quadrato", "Cerchio", ecc. Come calcestruzzo. Ma se non è immediatamente chiaro, è un suggerimento utile.

Si consiglia inoltre di seguire le convenzioni di programmazione locale e le guide di stile.

Answer 5

Penso che in parte dipenda da come userete la lezione. Se è inteso solo per uso interno nel forzare le classi derivate a conformarsi a un'interfaccia, quindi aggiungere Abstract prima potrebbe non essere una cattiva idea. Tuttavia, se stai fornendo una fabbrica Foo che fornirà istanze di Foo che sono in realtà SpecializedFoo1 o SpecializedFoo2, allora sembra difficile restituire istanze di AbstractFoo.

Answer 6

Penso che questa convenzione di denominazione venga utilizzata solo perché è difficile trovare un altro buon nome. Se hai già un'interfaccia chiamata "Elenco", come si chiamerebbe la classe "AbstractList"? Si tratta di evitare le discordanze sui nomi e quindi di fornire dettagli sull'implementazione.

Answer 7

Un po 'difficile da spiegare ma lo uso solo per evitare di copiare/incollare lo stesso codice in classi funzionali e non in qualcosa come oggetti di dominio.

• AbstractServiceTestCase -> L'Estratto prefisso sembra utile
• AbstractAnimal -> Sembra strano e inutile

Si dovrebbe naturalmente decidere per te, fino a quando la stessa convenzione è seguito tutto il progetto .

Answer 8

Le risposte finora sono molto utili e mostrano una diffusione responsabile della pratica. Tendo a convenire che i nomi non dovrebbero indicare l'implementazione (Foo potrebbe essere una classe astratta che è stata successivamente spostata su un'interfaccia). Tuttavia è utile per me quando si scrive codice per avere indizi visivi che ho bisogno di fornire metodi per classi derivate.

Come esempio, attualmente ho una gerarchia (non chiedere informazioni sulla base dei nomi ma sono significativi nel contesto e mappano sui nomi degli elementi XML).Sto utilizzando Java, ma penso che la maggior parte delle lingue sarebbero simili:

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

ora sto tendente:

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

piuttosto che

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

o

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

Personalmente posso ricordare che Marker è un concetto funzionale astratto e le sottoclassi sono implementazioni concrete.

Answer 9

Non direi classi astratte astratta per il seguente motivo:

Ogni Rettangolo è una forma. Ovunque tu possa usare una forma, puoi usare un rettangolo. Il codice che si occupa di un rettangolo (ma che può anche trattare con i cerchi) potrebbe sembrare:

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

Utilizzando un oggetto (ad esempio un rettangolo) ovunque sia possibile utilizzare una generalizzazione di essa (ad esempio, una forma) è un importante parte del concetto orientato agli oggetti e noto come Liskov Substitution Principle. (È anche ovvio: che tipo di frase o logica farebbe affermazioni sulle forme, ma non essere applicabili ai rettangoli?)

Se si nomina la generalizzazione a AbstractShape, questo principio viene violato. Un rettangolo non è una forma astratta. Se mai è una "Forma concreta"! Un rettangolo non è astratto (nel senso di "Non so che tipo di forma sia. Potrebbe essere un rettangolo, potrebbe essere qualsiasi altra cosa."). Codice utilizzando AbstractShape quindi legge sbagliata:

AbstractShape s = new Rectangle(...); 

ho bloggato con più pensieri su questo argomento here.