Devo aggiungere un prefisso "astratto" alle mie classi astratte? [chiuso]

Supponiamo che io abbia una classe astratta chiamata Task.

C'è uno standard o una convenzione che suggerirebbe che dovrei nominarlo AbstractTaskinvece?

Secondo Bloch's Effective Java (Item 18), il prefisso Abstract è una convenzione utilizzata in un caso speciale.

È possibile combinare le virtù di interfacce e classi astratte fornendo una classe di implementazione scheletrica astratta da abbinare a ciascuna interfaccia non banale che si esporta. ... Per convenzione, le implementazioni scheletriche sono chiamate AbstractInterface, dove Interface è il nome dell'interfaccia che implementano.

Ma Bloch sottolinea anche che il nome SkeletalInterface avrebbe avuto senso, ma lo conclude

la convenzione astratta è ormai saldamente stabilita.

Come hanno indicato altre risposte, in generale non c'è motivo di applicare questa convenzione di denominazione a tutte le classi astratte.

Non c'è convenzione. Si tratta di ciò che ti aiuterà, in qualità di sviluppatore, a programmare più velocemente e meglio e ad aiutare gli altri a capire il tuo codice.

Chiedi alle persone che vedranno e manterranno il codice. Cosa preferirebbero vedere? Cosa li renderà più facili? Quindi chiamalo in base a ciò che vorrebbero.

In un'altra nota, le Convenzioni sul codice per il linguaggio di programmazione Java: 9. Le Convenzioni di denominazione non suggeriscono alcun requisito:

I nomi delle classi dovrebbero essere nomi, in caso misto con la prima lettera di ogni parola interna in maiuscolo. Cerca di mantenere i nomi delle tue classi semplici e descrittivi. Usa parole intere per evitare acronimi e abbreviazioni (a meno che l'abbreviazione non sia molto più ampiamente utilizzata rispetto alla forma lunga, come URL o HTML).

No. Intellisense mi dirà banalmente se è astratto, quindi stai solo violando DRY qui.

Questa è in qualche modo una questione di preferenza (ma una cattiva pratica limite), ma alla maggior parte delle persone non piace vedere parte delle qualificazioni in nome della classe.

La maggior parte degli IDE renderà comunque facilmente disponibili tali informazioni, quindi non è necessario inserirle nel nome e sarà più semplice ometterle. Ricorda la notazione ungherese per la denominazione variabile, e questa è certamente considerata una cattiva forma oggi. Consiglio di chiamarlo semplicemente Task.

In .NET viene spesso visto l'uso di "Base" come suffisso per indicare una classe base astratta. Rimanderei alle altre risposte se questa è una pratica comune in Java.

Secondo me, il nome di un'entità non dovrebbe trasmettere informazioni sulla sua struttura di tipo, ma sulla sua semantica. Quindi non ha senso definire la tua classe come "AbstractSomething" se l'astrazione non fa parte del suo obiettivo di runtime. Che si tratti di una classe astratta di base è visibile per il programmatore e non deve riflettersi nel nome.

Tuttavia, se rende perfetto chiamare un'implementazione di una fabbrica astratta un AbstractFactory, perché ciò si riferisce all'intento della classe.

In generale, favorisci una convenzione di denominazione che aiuti a comunicare il maggior numero di informazioni sull'obiettivo della tua classe.

Allo stesso modo, stai alla larga da SomethingImpl. Non ci interessa che si tratti di un'implementazione e non di una classe base. Se la tua gerarchia di classi è progettata correttamente per l'ereditarietà, allora qualcuno potrebbe ereditarne. Sicuramente non ci sarebbe alcun valore in essi aggiungendo più suffissi "Impl" o altri artefatti. Inoltre, non è utile aggiungere un suffisso "Interfaccia" o il prefisso "I".

Ritenere:

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

Al contrario di:

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

Preferisco di gran lunga quest'ultima.

Questo, in un certo senso, simile al palese abuso della notazione ungherese che quest'ultima gli ha dato la sua cattiva reputazione , poiché le persone hanno iniziato erroneamente a interpretarlo come se richiedessero agli sviluppatori di aggiungere il prefisso alle loro variabili con un indicatore del tipo di variabile. Mentre a volte questo può avere i suoi usi (soprattutto se sei pigro a cercare la definizione del tipo), è per lo più inutile. L'idea originale di Simonyi con la Notazione ungherese era di usarla come un mnemonico per ricordare allo sviluppatore le capacità dell'entità, non del suo tipo.

Una buona regola empirica è quella di non includere le proprietà in un nome che sono evidenti dalla sintassi. Dato che in Java, è necessario contrassegnare una classe astratta con la abstractparola chiave con nome appropriato , non la includerei nel nome. In C ++, ad esempio, il caso non è così chiaro, ma almeno il compilatore ti dirà quando hai usato erroneamente una classe astratta. In qualcosa come Python di nuovo, nominare esplicitamente una classe astratta come tale non è una cattiva idea.

La solita eccezione alla regola è quando il nome è ambiguo. Se, per qualsiasi motivo, esiste una sottoclasse concreta Task(in altri esempi, questo può essere più sensato, ma comunque), allora sicuramente, usa AbstractTask.

protected abstract SomeClass { }

Questo mi dice che questa è una classe astratta. L'aggiunta di un prefisso è una tautologia e un anti-pattern e non è appropriato nella maggior parte dei casi, vedere ad esempio il collegamento in cui si parla di package localessere un'eccezione.

Nella maggior parte dei casi, le Abstractclassi non dovrebbero far parte di un'API pubblica, se è così dovrebbe esserci davvero una buona ragione e una buona ragione dovrebbe fornire un nome ovviamente diverso da quello AbstractSomeClass.

Nella maggior parte dei casi, se non riesci a trovare un nome più descrittivo, probabilmente dovrai riprogettare.

I miei cinque centesimi, probabilmente avrai implementazioni di quella classe astratta e saranno chiamate "SomeSpecificTask", "TaskWithBubbles", "StrangeTask" ecc. Quindi non ci sarà uno scontro di nomi tra il tuo "Task" astratto e loro.

Inoltre, la parola "astratta" riguarda la sintassi del linguaggio, non le entità del dominio aziendale, quindi preferirei non usarla come parte del nome.

D'altra parte, in una risposta qui ho visto un estratto di J.Bloch Effective Java che afferma che l'uso di "abstract" come parte di un nome è una pratica consolidata. Potrebbe essere così. Ma comunque nelle convenzioni ufficiali del codice Java non c'è nulla al riguardo.

Se lavori in un team, l'intero team deve decidere se aggiungere il prefisso alle classi astratte con "Abstract".

Se lavori da solo, dipende solo da te, non da me o da chiunque altro su questo sito.

Non sono uno sviluppatore Java (INAJD?) E non conosco la nomenclatura standard per tali cose, ma penso che Tasksuoni abbastanza astratto da poter essere solo così com'è.

E se vuoi scrivere una AbstractSyntaxTreelezione astratta ? O forse solo un abstract SyntaxTree?

Non è convenzionale e può facilmente confondere le persone.

Ho fatto questo. Ho aggiunto "Abstract" come prefisso alla mia classe astratta denominata AbstractOperation. La ragione per cui l'ho fatto è che c'era un altro pacchetto che aveva una classe non astratta chiamata Operation, e ha aiutato il mio team e i programmatori che hanno preso il controllo in seguito per evitare qualsiasi confusione tra i due.