Identifica quale modello si adatta meglio

Se tutti i tuoi comandi possono essere gestiti utilizzando lo stesso algoritmo, allora dovrebbe funzionare con il metodo Template. Vale a dire. delegare i passaggi effettivi per il comando delle sottoclassi.

Riguardo la tua domanda sui comandi che hanno argomenti diversi nel costruttore. La costruzione di oggetti non è un problema con il modello Template (in quanto è un modello "comportamentale" e non "creazionale". Utilizza un factory di comando per questo.

Non hai bisogno di un modello per tutto! Se un modello non si adatta, non utilizzarne uno! Basta capire cosa devi fare e trovare il metodo più semplice per farlo.

In questo momento, è di moda dire cose come "i modelli non sono un proiettile d'argento" senza alcun tipo di razionalizzazione. È un copout: i pattern do hanno un uso.

In questo caso, dalla tua descrizione, la tua situazione odora di metodo template + il design regolare orientato agli oggetti potrebbe essere un primo piano di attacco adatto.

L'utilizzo di un motivo non è sempre la risposta corretta. Sì, è bello provare a usare gli schemi, ma quando pensi al modello come a un martello, non fare di ogni problema l'unghia.

Solo perché puoi non è una buona ragione per fare qualcosa. Usa uno schema esistente se esiste, ma non calzare una soluzione in uno schema esistente. Tuttavia, se hai un sacco di cose simili, generalizza la funzionalità comune.

Nel mio primo lavoro, ho creato molti programmi COBOL che funzionavano a memoria limitata. Per fare questo ho usato due procedure mainline. La maggior parte dei programmi utilizzava il semplice modulo:

• inizializza (apri file, variabili e buffer)
• process (fai qualunque cosa il programma dovrebbe fare)
• cleanup (scrivi fine report, chiudi file)

I report che richiedevano ordinamenti di dati consistevano in una linea principale più lunga:

• inizializza (apri file, variabili e buffer)
• estrai i dati (feed data route route lines con chiavi invertite)
• ordina i dati
• genera un rapporto (leggi i dati ordinati e genera il rapporto)
• cleanup (scrivi fine report, chiudi file)

L'impostazione di convenzioni e generalizzazioni può velocizzare lo sviluppo della codifica. Ancora più importante, di solito è più semplice trovare bug. Se violate le convenzioni, potrebbe essere più difficile trovare dove avete introdotto il bug.

Nel tuo caso puoi affrontare il problema sia in modo sincrono che asincrono. Il metodo sincrono saresti do_command( returns response ) . I metodi asincroni sono send_command( returns commandSent ) e handleInterrupt( receives response ) . L'opzione asincrona è più difficile da gestire in quanto è necessario avere da qualche parte per handleInterrupt per l'output dei risultati. Inoltre, l'uomo ha bisogno di semafori di esclusione per impedire l'invio di comandi mentre è in corso un comando precedente. I metodi do_command o send_command avrebbero mappato uno a uno ai tuoi comandi. handleInterrupt dovrebbe conoscere o derivare quale tipo di dati aspettarsi.

È difficile dire senza visualizzare il codice ... Ma questo suona più come un refactoring che con i pattern.

Leggi memoria, cancella memoria e scrivi sono tutte operazioni di memoria in modo che possano avere una classe / struttura "MemoryArea" condivisa (che è sia un indirizzo che una lunghezza). Scrittura richiederebbe un parametro aggiuntivo di Dati.

Invia, aspetta, tratta sono comandi. Potrebbe essere appropriato usare un modello di comando. Potrebbe anche essere opportuno avere un'interfaccia comune o un modello di metodo Template su queste classi, in modo che le funzioni comuni possano essere chiamate sequenzialmente da un livello superiore. Puoi anche guardare al modello di strategia ... ma non si adatta veramente qui.

Puoi usare una fabbrica che costruisce una classe comunemente interfacciata ... ancora difficile da dire.

Vorrei raccomandare il primo libro dei modelli di testa.

Ho letto Patterns di progettazione: elementi del software orientato agli oggetti riutilizzabile e ho imparato molto da esso. Tuttavia, non avvio un programma pensando a schemi che possono essere applicati. Quando avvio un programma, non penso alla forma finale del programma. Invece, penso al primo test unitario che dovrei scrivere.

Per il tuo programma, potrei prima scrivere un test per leggere la versione del dispositivo. Dopo averlo fatto funzionare, potrei scrivere un altro test unitario per scrivere memoria, quindi rileggerlo e accertarmi che i dati letti corrispondano ai dati scritti. Se si effettua il refactoring del codice man mano che si procede, a un certo punto si potrebbe notare che un particolare modello di progettazione può aiutare a ridurre la duplicazione del codice. O forse no. Va bene. Utilizzare i modelli OO non rende necessariamente il codice migliore.

Dovresti pensare a schemi di progettazione come soluzioni per la codifica dei problemi di manutenzione. Quando viene visualizzato un problema, se nessuna soluzione è chiara per te, consulta il libro e verifica se alcuni modelli corrispondono al tuo problema.

Ad esempio, è possibile che il supporto di un nuovo sottocomando del programma richieda la modifica di molte classi. Se dovessi affrontare questo problema, penserei al mio modo ideale di supportare un nuovo comando. Potrei decidere che sarebbe meglio se potessi supportare un nuovo sottocomando implementando una nuova classe. Se non fossi sicuro di come farlo accadere, potrei scansionare gli schemi del libro e forse deciderei che una combinazione di modelli Factory e Command funzionerebbe.