È fuorviante etichettare il codice come un particolare modello di progettazione se solo si adatta alla definizione in modo approssimativo?

Question

È fuorviante etichettare il codice come un particolare modello di progettazione se solo si adatta alla definizione in modo approssimativo?

#1 da (5 voti)
#2 da (2 voti)
#3 da (0 voti)

3

Sfondo:
Ho una comprensione approssimativa, ma di lavoro dei ~ 15 schemi di progettazione. È stata la mia esperienza nell'uso di modelli di progettazione nei miei progetti che le implementazioni risultanti di solito finiscono come alcune varianti di un modello e non sempre si adattano agli esempi di libri di testo canonici.

Caso:
Trovo utile lasciare commenti di tipo tag che suggeriscano un archetipo sottostante, ad esempio, nella seguente descrizione della classe Javadoc, l'etichetta " [Singleton] " viene utilizzata semplicemente per descrivere che c'è solo uno di questi oggetti usati in un dato momento. Questa classe può o non può essere impostata su "limitare l'istanza di una classe a un oggetto" - Wikipedia .

/**
 * [Singleton]
 * The manager of all jewels, which are stored here in collections.
 */
public class JewelManager implements IDestroyable
{

Contesto:
Sto lavorando a un team con molti altri sviluppatori, ma ho bisogno di assumere che ci possano essere altri sviluppatori che lavorano al progetto con i quali mai avranno l'opportunità di parlare.

Domanda:
È fuorviante etichettare classi o metodi come un particolare modello di progettazione (Strategia, Mediatore, ecc.) Se si adattano solo vagamente a tale definizione?

object-oriented comments design-patterns documentation object-oriented-design

posta pup 13.12.2014 - 17:27

fonte

3 risposte

Leggi altre domande sui tag object-oriented comments design-patterns documentation object-oriented-design

Come evitare lunghe catene di chiamate? Il modo migliore per controllare la versione di una configurazione enorme per un'applicazione?

score 5 · Answer 1

Is it misleading to label classes or methods as a particular design pattern (Strategy, Mediator, etc.) if they only loosely fit that definition?

Dipende.

Se hai un singleton e non impedisce l'istanziazione, sarebbe fuorviante etichettarlo come un singleton, dato che è non un singleton . È una variabile globale. Fare altrimenti porta i tuoi colleghi sviluppatori a fare supposizioni (ragionevoli), che saranno sbagliate, che porteranno a errori sottili e catastrofici.

Se hai detto ... una fabbrica che restituisce nuovi oggetti casuali piuttosto che nuovi oggetti basati sull'input alla fabbrica. Probabilmente è giusto chiamarlo una fabbrica. I tuoi colleghi programmatori non dovrebbero sapere (o preoccuparsi) dei suoi dettagli di implementazione. E questa nuova implementazione, pur non essendo una fabbrica in sé, non infrange il contratto implicito di una fabbrica: "mi dai X e ti darò una nuova Y".

score 2 · Answer 2

Etichettare un modello come [X] in Javadoc non è davvero così utile. Troppi modelli sono applicati in modo errato perché gli sviluppatori non convalidano le ipotesi dei modelli (che non sono anche documentati).

Il tuo esempio Singleton è banale, poiché Singleton è più un idiom che un modello di design.

Esiste almeno un progetto ( link ) che utilizza annotazioni Javadoc per l'etichettatura di elementi di un modello di progettazione in Java. Vedi link

Direi che l'applicazione di pattern non richiede solo etichette / annotazioni degli elementi (il cosa ), ma anche giustificazioni con ipotesi (il perché ).

Considera Visitatore:

Le etichette dovrebbero essere applicate alle classi nella gerarchia di elementi (almeno Element) e alla gerarchia di visitatori (non è necessaria se si utilizza la parola Visitor nel modello).

Presupposti (che potrebbero essere documentati nell'interfaccia Visitor, suppongo):

Si prevede che la gerarchia degli elementi non si evolva (altrimenti i tuoi visitatori avranno tutti bisogno di essere modificati).
Si prevede che la gerarchia dei visitatori ottenga nuovi ConcreteVisitors in futuro (il che giustifica la complessità di Visitor).

Se si dispone di un solo ConcreteVisitor, potrebbe essere difficile giustificare la complessità della doppia spedizione (che influisce sulle prestazioni e rende più difficile il debug del codice). La maggior parte di tutti i modelli di progettazione sono investimenti in complessità che dovrebbero ripagare se le ipotesi sono corrette (ad es., Visitatore vale la pena se è necessario aggiungere nuove funzionalità e la struttura dell'elemento è stabile). Rompi queste ipotesi e alla fine potrebbe essere un brutto progetto.

Purtroppo, molte pagine wiki sui pattern non menzionano questi punti di forza / debolezza. Torna ai riferimenti GoF o a un buon libro sui pattern per i dettagli.

score 0 · Answer 3

Is it misleading to label classes or methods as a particular design pattern (Strategy, Mediator, etc.) if they only loosely fit that definition?

No, non è fuorviante; piuttosto non dovrebbe essere.

Comprensione degli ostacoli eccessivi . Se diciamo che una variabile di sola lettura globale è un singleton, non è "loose" che è semplicemente sbagliato. Inoltre, in senso stretto un "singleton" è come l'oggetto è costruito; quell'oggetto potrebbe benissimo essere uno dei schemi strutturali .
I costrutti del linguaggio moderno possono farci aderire all'intento di un determinato modello di design, ma deviare dal modello classico della classe come mostrato in GoF libro. Ad esempio nel modello di comando, i comandi concreti sono sottoclassi (o implementano un'interfaccia). Tuttavia si potrebbe usare un delegato per il "metodo di comando" senza sottoclassi. L'obiettivo del modello di comando è soddisfatto: disaccoppiamento del richiedente dall'esecuzione della richiesta.
Questioni relative all'intenzione . C'è una somiglianza tra alcuni modelli ma la leggera, apparentemente inutile, differenziazione esprime l'intento del modello. Ad esempio, guarda la sorprendente somiglianza tra Composito e Decorator patterns.
Specificità . Ad esempio non è sufficiente dire "fabbrica". " Metodo di fabbrica ", " Classe di produzione " e " Fabbrica astratta " esprimono sempre più soluzioni complesse all'idea generale di separare la costruzione dell'oggetto dal suo uso. Quindi considera il pattern Builder che potrebbe essere descritto come una fabbrica astratta flessibile.