È mai una buona idea usare il nome del modello di progettazione nelle classi di implementazione? [chiuso]

Recentemente mi sono imbattuto in un moderatamente grande base di codice Python con un sacco di MyClassAbstractFactory, MyClassManager, MyClassProxy, MyClassAdapterecc classi.

Mentre da un lato quei nomi mi hanno indicato la ricerca e l'apprendimento dei modelli corrispondenti, non erano molto descrittivi di ciò che la classe fa .

Inoltre, sembrano rientrare nella lista proibita di parole in programmazione: variable, process_available_information, data, amount, compute: eccessivamente ampi nomi, che non ci dicono nulla sulla funzione quando viene utilizzato da loro stessi .

Quindi dovrebbe esserci CommunicationManagero meglio PortListener? O forse non capisco affatto il problema ...?

• AbstractFactoryè davvero una cattiva scelta per un nome. Non c'è modo di sapere cosa viene creato da questa fabbrica e quando cercherai un'entità che crea Animals, non troverai mai la fabbrica corrispondente per nome.

• AnimalAbstractFactorynon è nemmeno una scelta saggia, poiché nella maggior parte delle lingue sarebbe ridondante con la abstractparola chiave nella firma.

  Detto questo, ci sono molte buone ragioni, evidenziate dai commenti, da includere effettivamente Abstractnel nome: non solo ci sono diversi contesti in cui non hai la firma completa, ma solo il nome, ma anche, mantenendo AnimalFactoryun'interfaccia può essere una scelta saggia (a meno che, sfortunatamente, la convenzione del linguaggio / framework non abbia come prefisso le interfacce I).

• AnimalCreationUtilitysarebbe anche una cattiva scelta: se si tratta di una fabbrica , rendere le cose più facili per le persone che leggeranno il codice e lo chiameranno fabbrica .

• abstract AnimalFactoryva bene Non ha ridondanza ed è chiaro che si tratta di una fabbrica astratta che delega la creazione di animali ai suoi figli.

Quindi sì, includere il nome del modello di progettazione è una buona idea, ma dovrebbe essere solo una parte del nome e non dovrebbe essere ridondante con le altre parti della firma.

Dipende dall'esempio specifico. Il modello Builder è quasi sempre meglio servito nominando la tua classe * Builder, mentre di solito un Singleton non ha bisogno di essere nominato come tale.

Se non inserisci il nome del modello nel nome della tua classe, e forse anche se lo fai, dovresti generalmente inserire un commento nella classe che spieghi che implementa un modello specifico.

Il punto centrale dell'uso dei nomi dei pattern nelle classi è quello di rendere facile capire cosa fa la classe. Se si chiama la classe AnimalFactory è ovvio che la classe crea istanze Animal. Se il nome della tua classe include un nome di un modello e non descrive ciò che fa, hai scelto un modello sbagliato o lo hai implementato in modo errato.

Penso che possa funzionare davvero bene. Per esempio:

// Command for retrying card entry with CVN.
public class RetryCardEntryWithCVNCommand { ... }

// Query for getting expired accounts
public class GetExpiredAccountsQuery { ... }

// Decorator for logging exception. Implies that it's an additional 
//mechanism for logging exceptions.
public class LogExceptionToDbDecorator { ... }

// Factory for creating account filters
public class AccountFilterFactory { ... }