2009-03-23 8 views
14

Durante il mio ultimo progetto ho notato, che è molto conveniente, includere i nomi dei modelli di progettazione nei nomi delle classi. Per esempio:Quando includere un nome di modello di disegno nel nome della classe?

  • ContextLazyFactory
  • RunOnceMediator
  • ThirdPartyMediator
  • MyProjectCliFacade
  • BinaryGate

Rende il progetto di facile lettura. Ulteriore vantaggio è che non userete i vostri nomi come "RunOnceManager", "ContextDelayedConstruction", "ThirdPartyInterface", ecc. Che potrebbero avere un significato acuto solo per l'autore. D'altra parte, non mi piacerebbe vedere classi come vector_container nell'STL. Come pensi?

La mia vista corrente su questo argomento è: le classi che sono nodi importanti nella gerarchia di classi dovrebbero avere il loro modello di progettazione nel loro nome, per enfatizzare la struttura gerarchica e rendere il progetto molto più facile da leggere.

risposta

20

Mi sembra naturale per me, in molti casi:

  • I design pattern sono chiamati a spiegare quello che fanno
  • classi sono chiamati a spiegare quello che fanno

Quando il modo più semplice di spiegare lo scopo di una classe è in termini di design pattern, perché non usarlo?

D'altra parte, quando lo schema di progettazione è per lo più accidentale quindi escluderlo. Ad esempio, una classe può capitare di essere un singleton, ma questo non è il suo scopo principale nella vita, quindi non mi aspetterei di vedere "Singleton" nel nome. Confrontalo con una fabbrica il cui scopo principale è quello di essere una fabbrica per altri oggetti - "FooFactory" ha perfettamente senso.

+1

Downvoters: si prega di fornire un commento per spiegare perché non si è d'accordo con una risposta quando si downvote. –

+0

+1 completamente d'accordo. – eglasius

+0

@Jon in questo caso, penso che sia giusto ipotizzare che i downvoters si sentano forti nel metterli nel nome o nel non metterli affatto, in entrambi i casi non penso che si possa fare molto con queste informazioni (oltre che entrare una lunga discussione a riguardo). – eglasius

0

Sono d'accordo con te. L'unica cosa che aggiungerei (il che è ovvio) è assicurarsi che il nome del modello all'interno del nome della classe usi il modello attuale impiegato.

Una volta ho visto una classe chiamata XxxxFactory (o qualcosa del genere) e non aveva alcuna somiglianza con un modello di fabbrica qualunque!

0

Uso anche il nome del modello di progettazione nei nomi di classe per aumentare la leggibilità e facile da capire per altre persone.

I vettori significano già per me una collezione, quindi non è necessario per la raccolta. Btw container non è un design pattern.

0

Se il nome risultante è sufficientemente chiaro, procedere e utilizzarlo.

Ma ci possono essere circostanze che il nome risultante sia o maldestro o vago. In tal caso, utilizzare il nome più appropriato.

1

Penso che l'uso di modelli di design nei nomi sia una grande idea .Ad esempio, in uno dei miei giochi che ho:

GameLevelAbstract 
InGameArea 
MainMenu 

I secondi due classi (InGameArea e MainMenu) sottoclasse GameLevelAbstract ed implementare è metodi virtuali puri. Posso vedere nella mia vista di origine che quella classe è astratta e immediatamente sa che è o non è quello che sto cercando.

Un altro esempio è la mia facciata grafica:

GraphicsFacade 
OpenGLGraphics 
DirectXGraphics 

Esattamente la stessa messa a punto, come ho avuto in precedenza, se non che si tratta di grafica.

Trovo che utilizzare lo schema di progettazione nel nome sia utile e informativo quando cerco una classe. Credo che alcune cose non dovrebbero essere usate nel nome Singleton, tuttavia Flyweight, Factory o Facade sono esempi di nomi di design che ritengo adatti al nome di una classe che implementa tali modelli.

Penso che se si utilizzano nomi di classi validi che aiutano il programmatore a comprendere bene ciò che la propria classe fa a colpo d'occhio è una buona cosa.

Non penso che affermare qualcosa sia una struttura di dati o un algoritmo è una buona cosa nella maggior parte dei casi. "LinkedListDataStructure" o "BubbleSortAlgorithm" non aggiungono nulla alla comprensione del programmatore della classe poiché "LinkedList" è ovvio nella sua funzione.

+0

+1 Mi piace anche mettere "astratto" nel nome della classe per le classi astratte. La convenzione di denominazione .NET standard sarebbe "MyClassBase", ma preferirei "AbstractMyClass" – MattDavey

+0

* "LinkedListDataStructure" o "BubbleSortAlgorithm" non aggiungono nulla alla comprensione del programmatore. * Completamente d'accordo anche con questo. Il nome della classe è parte della sua interfaccia e l'interfaccia non dovrebbe pubblicizzare dettagli di implementazione come questa .. Peccato non posso +2 tu;) – MattDavey

+1

Non mi piace 'Abstract' nei nomi delle classi base perché quando I vedi che 'X' deriva da' Y', penso che 'X' sia un _type_ di' Y' (ad esempio, 'Dog' è un tipo di' Animal', non un 'AbstractAnimal'). Sebbene una variabile di tipo 'AbstractY' sia un riferimento astratto, non punta a qualcosa che è astratto. –

0

C'è almeno un inconveniente: se, per qualsiasi motivo, la classe non utilizza il modello dopo un refactoring, è necessario rinominarlo o disporre di una classe con un nome errato.

+1

Accetto, ma uno schema di progettazione indica il comportamento di un oggetto. Se dopo aver refactoring l'oggetto non si comporta in remoto allo stesso modo, forse avrebbe dovuto essere una nuova classe invece ... – MattDavey

0

È davvero utile aggiungere nomi di modelli di progettazione come nome classe. Che rendono il codice più facile da capire. I nomi delle classi dovrebbero essere significativi e riflettere la funzionalità della classe. Quando si aggiunge il nome del modello nel nome della classe, aggiunge più leggibilità in quanto riflette anche la tecnica che è stata utilizzata per progettare la classe. Preferisco questo tipo di nome di classe.

Problemi correlati