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

• AbstractFactory è davvero una scelta sbagliata per un nome. Non c'è modo di sapere che è stato creato da questa fabbrica e quando cercherete un'entità che crea Animal s, non troverete mai la corrispondente fabbrica per nome.

• AnimalAbstractFactory non è nemmeno una scelta saggia, poiché nella maggior parte delle lingue sarebbe ridondante con la parola chiave abstract nella firma.

  Detto questo, ci sono diversi buoni motivi, evidenziati dai commenti, per includere effettivamente Abstract nel nome: non solo ci sono diversi contesti in cui non si ha la firma completa, ma solo il nome, ma inoltre, mantenere AnimalFactory per un'interfaccia può essere una scelta saggia (a meno che, sfortunatamente, la convenzione del linguaggio / framework non preceda le interfacce con I ).

• AnimalCreationUtility sarebbe anche una scelta sbagliata: se è una factory , semplificare le cose per le persone che leggeranno il codice e chiamarlo factory .

• abstract AnimalFactory è ok. Non ha ridondanza ed è chiaro che è 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 dallo specifico esempio. Il modello di Builder è quasi sempre meglio servito nominando la tua classe * Builder, mentre un Singleton di solito 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 spiega che implementa un modello specifico.

L'intero punto di utilizzo dei nomi dei pattern nelle classi è quello di rendere più facile capire cosa fa la classe. Se chiami la classe AnimalFactory è ovvio che la classe crea istanze di Animal. Se il nome della tua classe include un nome di un pattern e non descrive quello che hai, hai scelto uno schema sbagliato o l'hai implementato in modo errato.

Penso che possa funzionare davvero bene. Ad 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 { ... }