Dovrei aggiungere un prefisso "Abstract" alle mie classi astratte? [chiuso]

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

You can combine the virtues of interfaces and abstract classes by providing an abstract skeletal implementation class to go with each nontrivial interface that you export. ... By convention, skeletal implementations are called AbstractInterface, where Interface is the name of the interface they implement.

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

the Abstract convention is now firmly established.

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

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

Non c'è alcuna convenzione. Tutto dipende da ciò che ti aiuterà, come sviluppatore, a codice più veloce e migliore e ad aiutare gli altri a capire il tuo codice.

Chiedi alle persone che vedranno e manterranno il codice. Cosa preferirebbero vedere? Cosa renderà più facile per loro? Quindi denominalo in base a ciò che vorrebbero.

Su un'altra nota, Convenzioni sui codici per il linguaggio di programmazione Java: 9. Convenzioni sui nomi suggerisce nessun requisito:

Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).

Questo è in qualche modo una questione di preferenza (ma le cattive pratiche borderline), ma alla maggior parte delle persone non piace vedere una parte dei qualificatori nel nome della classe.

La maggior parte degli IDE renderà queste informazioni facilmente disponibili, quindi non è necessario inserirle nel nome e sarà più semplice ignorarlo. Ricorda la notazione ungherese per la denominazione delle variabili, e questo è certamente considerato una cattiva forma al giorno d'oggi. Raccomando semplicemente di chiamarlo Task .

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

A mio parere, 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 sia una classe astratta di base è visibile per il programmatore e non ha bisogno di essere riflessa nel nome.

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

In generale, favorisci le convenzioni di denominazione che aiutano a trasmettere la maggior parte delle informazioni sull'obiettivo della tua classe.

Allo stesso modo, tieni chiaro 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 ereditare da essa. Sicuramente non ci sarebbe alcun valore aggiunto aggiungendo più suffissi "Impl" o altri artefatti. Non c'è alcun valore nell'aggiungere un suffisso "Interfaccia" o prefisso "I".

Si consideri:

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

Al contrario di:

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

Preferisco di gran lunga il secondo.

Questo, per certi aspetti, è simile al uso scorretto del Notazione ungherese che quest'ultimo gli ha dato la sua cattiva reputazione , poiché le persone hanno iniziato erroneamente a interpretarlo come obbligando gli sviluppatori a prefisso le loro variabili con un indicatore del tipo di variabile. Anche se a volte questo può avere i suoi usi (soprattutto se sei pigro per cercare la definizione del tipo), è per lo più inutile. L'idea originale di Simonyi con la notazione ungherese era di usarla come mnemonico per ricordare allo sviluppatore le capacità dell'entità, non del suo tipo.

Una buona regola empirica è di non includere le proprietà in un nome che sono evidenti dalla sintassi. Poiché in Java, devi contrassegnare una classe astratta con la parola chiave abstract 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 in modo errato una classe astratta. In qualcosa di simile a Python, nominare esplicitamente una classe astratta in quanto tale non è una cattiva idea.

La solita eccezione alla regola è quando il nome è ambiguo. Se, per qualsiasi ragione, esiste una sottoclasse di% Task (in altri esempi, questo può essere più ragionevole, ma qualunque sia), quindi sicuro, usa AbstractTask .

protected abstract SomeClass { }

Questo mi dice che questa è una classe astratta. L'aggiunta di un prefisso è un tautologia e anti-pattern e non appropriato nella maggior parte dei casi, vedi il link dove si parla di package local come eccezione, per esempio.

Nella maggior parte dei casi, le classi Abstract non dovrebbero far parte di un'API pubblica, se ci dovrebbe essere davvero una buona ragione e una buona ragione dovrebbe fornire un nome ovviamente buono diverso da AbstractSomeClass .

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

I miei cinque centesimi, Probabilmente avrai implementazioni di quella classe astratta e saranno chiamati 'SomeSpecificTask', 'TaskWithBubbles', 'StrangeTask' ecc. Quindi non ci sarà un conflitto tra il tuo astratto 'Task' e loro.

Inoltre, la parola 'abstract' riguarda la sintassi del linguaggio, non le entità del dominio aziendale, quindi preferirei non usarlo come parte del nome.

D'altra parte, in una sola risposta ho visto un estratto da J.Bloch Effective Java che dice che usare "astratto" come parte di un nome è una pratica consolidata. Potrebbe essere così. Ma comunque nelle convenzioni ufficiali del codice java non c'è niente a riguardo.

Se lavori in una squadra, l'intera squadra deve decidere se devi anteporre le classi astratte a "Abstract".

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

Non sono uno sviluppatore Java (INAJD?) e non conosco la nomenclatura standard per cose del genere, ma penso che Task suona abbastanza astratto da poter stare da solo così com'è.

Che cosa succede se vuoi scrivere una classe AbstractSyntaxTree astratta? O forse solo un abstract SyntaxTree ?

Non è convenzionale e può facilmente confondere le persone.

L'ho fatto. Ho aggiunto "Abstract" come prefisso alla mia classe astratta denominata AbstractOperation. La ragione per cui l'ho fatto era che c'era un altro pacchetto che aveva una classe non astratta di nome Operation, e che ha aiutato la mia squadra e i programmatori a intervenire in seguito per evitare qualsiasi confusione tra i due.