Pattern da utilizzare per diverse fasi in un software

Question

Pattern da utilizzare per diverse fasi in un software

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

4

Sto sviluppando un software per un laboratorio per testare alcuni dispositivi. Per testare ogni dispositivo ci sono molti sottotest che dovrebbero essere fatti per raggiungere il risultato finale. Per eseguire un test completo, il software deve passare Stage1, quindi passa automaticamente allo Stage2 e poi allo Stage3 e così via fino al completamento dell'intero test. nel frattempo l'utente può scegliere di eseguire lo Stage3 o Stage2 o qualsiasi altra fase indipendentemente da eseguire (che seleziona in fase di esecuzione). questa è la cosa che ho fatto finora:

publicclassIronTestWorkFlow:ITestWorkFlow{privatereadonlyList<ITestStages>_testStageses;publicIronTestWorkFlow(List<ITestStages>testStageses){if(testStageses==null){thrownewArgumentNullException("testStageses");
            }
            _testStageses = testStageses;
        }
    }

Sto usando un contenitore DI. Ma non so come modificare l'elenco di fasi in ITestWorkFlow in fase di runtime.

Domande:

1- Sto progettando questo giusto?

2- Se sì quale schema dovrei seguire per obbedire ai principi e modificare gli stadi in fase di esecuzione? e come posso farlo?

c# dependency-injection design-patterns .net

posta Mehrdad Kamelzadeh 13.06.2013 - 21:52

fonte

4 risposte

Leggi altre domande sui tag c# dependency-injection design-patterns .net

La generazione emergente di programmatori ha avuto un'idea sbagliata dei modelli di progettazione? Qual è la migliore strategia per la licenza di un'applicazione desktop utilizzando un servizio Web, quando tutto ciò che devo sapere è quando le persone usano il prodotto?

score 1 · Answer 1

Le cose sono Bass-Akwards

Il termine tecnico per questo è l'inversione del controllo.

Il tuo costruttore di IronTestWorkFlow :

 public IronTestWorkFlow(List<ITestStages> testStageses )

Come sapevi quali fasi costruire prima di sapere che tipo di% di co_de stai costruendo? Non lo fai, ed è per questo che sei in questo dilemma, penso. Iniezione precoce.

Modello di fabbrica anziché contenitore DI

Usiamo il Pattern di fabbrica - inserisci Workflow e Workflow building in Stage e WorkflowFactory classi rispettivamente. Ad esempio, l'utente selezionerà un test di ferro, quindi viene chiamato StageFactory che a sua volta chiama IronTestWorkFlowFactory per creare gli stadi di cui ha bisogno. Quindi abbiamo il contesto necessario per costruire le fasi giuste.

Prendo dalla descrizione del problema che il codice di livello superiore dovrebbe essere in grado di richiamare un StageFactory o un WorkFlowFactory come desiderato, a seconda di quanto granulare o personalizzato di una cosa che l'utente desidera. Quindi assicurati che tutte le dipendenze tra le fabbriche avvengano tramite parametri; questa è la Dipendenza Iniezione di base. Un contenitore DI non è necessariamente richiesto per fare l'iniezione di dipendenza.

Resta orientato agli oggetti

Pensa a lungo alle cose che stai manipolando: StageFactory , Stage , altro? Concentrati innanzitutto sulle "strutture dati" fondamentali.

Fai attenzione a concentrarti troppo sul "quadro" astratto di alto livello senza un po 'di carne progettato nelle classi principali, il che si traduce in classi malamente non incapsulate con numerose violazioni del principio di responsabilità singola che determinano ulteriori accoppiamenti indesiderati e dolorosi.

Ad esempio, mi chiedo che cosa sia un WorkFlow - una lista ordinata di fasi - e quali operazioni fondamentali sono fatte con loro. Mi chiedo se ci sono alcune regole di business che definiscono l'ordine indipendentemente dall'ordine in cui vengono semplicemente istanziate? Se è così, implementare Workflow può fare una profonda differenza. Ci sono stato, fatto.

score 0 · Answer 2

Questo problema non ha necessariamente bisogno di essere risolto con schemi di progettazione ma, per rispondere alla tua domanda, puoi organizzare i test che ti servono usando un semplice elenco o usare un pattern composito se vuoi renderlo un po 'più complicato. Potresti quindi utilizzare diverse strategie per scorrere l'elenco dei test, ciascuna strategia che reagisce in modo appropriato a successo o fallimento.

Questa potrebbe non essere la soluzione finale, ma è uno spunto di riflessione ...

score 0 · Answer 3

Puoi utilizzare un schema del mediatore . Dovresti avere un elenco principale di tutti i test disponibili nel flusso di lavoro principale. Un utente non parlerà direttamente con questo flusso di lavoro, ma con il Mediatore. Il Mediatore tiene traccia di quali attività sono effettivamente selezionate (nel proprio elenco) e ne espongono all'utente.

score 0 · Answer 4

Sembrerebbe che ci siano una miriade di schemi che possono essere impiegati qui. Uno da considerare è lo schema State se è necessario passare automaticamente da un test a un altro (ciascuno Stato deve sapere come passare il suo contesto allo stato successivo, nel tuo caso, questi stati sarebbero i tuoi test di laboratorio specifici se ho capito il problema correttamente )

o potrebbe essere utile anche qualche variante di Chain of Responsibility.