Un design migliore? Stesso oggetto, diversi stati possibili

Question

Ho un'applicazione molto semplice che consiste in un sito front-end ASP.NET, con un servizio Windows WCF che esegue la pesante logica di back-end di sollevamento.

L'utente ha una pagina semplice in cui seleziona alcuni parametri e preme un pulsante "Invia". La pagina chiama il servizio WCF e gli passa i parametri. Il servizio ha istanziato un'istanza di una classe 'Job', inviando i parametri al costruttore, quindi chiama un metodo 'Run ()' che fa tutto il lavoro di - inserendo un record 'job' in un database con il nome dell'utente, l'ora avviato, ecc ... Invia una richiesta a un fornitore di terze parti, prende i dati, li inserisce nel database, esegue qualche altra logica aziendale, quindi contrassegna il lavoro come completato.

L'utente ha quindi una seconda pagina semplice in cui ora può cercare il suo lavoro (una casella combinata ricercabile ordinata per data, visualizzando più campi relativi a quel lavoro) e quindi visualizzare i dati corrispondenti a quel lavoro sullo schermo - ( la maggior parte dei campi della tabella dei lavori, ad esempio ora di inizio, ora di completamento, stato, ecc., visualizzati come etichette in un pannello) e i dati effettivi che abbiamo estratto dal fornitore di terze parti (resi come una griglia, sotto il pannello).

Passiamo ora alla mia domanda, quindi ho una classe Job che ha tutti i campi sopra menzionati, insieme al suo metodo Run () pubblico e ai costruttori. Ha alcune semplici funzioni private e diversi membri privati ??che sono interfacce per classi come IParser, IVendorConnection, IDataAccess - le classi che svolgono tutto il lavoro reale sopra descritto .. l'attuale classe Job e il metodo Run () non fanno molto lavoro effettivo, praticamente solo i delegati lavorano ai suoi oggetti compositi (tra l'altro per una buona testabilità).

Ora, questa classe Job ha 3 diversi possibili usi / stati. Il suo uso principale è all'interno del Servizio, per l'uso della funzione Run () per eseguire letteralmente un lavoro. Ha anche altri 2 usi: fungendo da modello per il pannello che ho descritto sopra e fungendo da modello per la casella combinata che ho descritto sopra. La classe di lavoro ha 3 costruttori pubblici, ognuno che lo imposta per uno dei 3 stati. In tutti i casi, ogni diverso "stato" si preoccupa solo di determinati membri di cui gli altri 2 stati non si preoccupano - in alcuni casi alcuni dei membri vengono utilizzati in tutti e 3 gli stati. Lo "stato della casella combinata" è il più semplice, in questo caso voglio solo 3 campi di sola lettura. Nello "stato pannello" mi occupo di 6 campi di sola lettura. Nello stato "lavoro" fondamentalmente sto creando questi valori di campo man mano che il lavoro avanza - e dovrebbero essere tutti privati.

Sto solo cercando un modo più pulito per farlo. Se istanzio una classe Job nello stato A, so che l'accesso al membro X non funzionerà o che la chiamata alla funzione Y fallirà. Tuttavia è ancora un codice compilabile.

Sono sicuro che altri abbiano già affrontato questo problema. Stavo pensando di avere una classe Job di base contrassegnata come MustInherit / abstract, e quindi avere 3 classi derivate, una per ogni stato. Metti i membri condivisi nella base e quelli specifici dello stato nel derivato e usa le classi derivate nel mio codice dove appropriato. Questo sembra abbastanza semplice per i miei scopi e risolve il mio problema. Forse potrei anche avere una sorta di JobFactory ... Immagino che sto solo cercando come gli altri hanno risolto questo dato che forse non sto pensando abbastanza fuori dagli schemi ... Ho avuto molte classi come macchine a stati prima nel mio giorni di sviluppo di giochi per hobbisti - ma era diverso, perché le istanze di quelle classi potevano cambiare stato (ad esempio, una classe "Enemy" poteva cambiare il suo stato da "modalità_attacco" ad "attesa") Nel mio caso, non ci sono stati che cambiano - una volta creato, un Lavoro deve rimanere nel suo stato e non tentare mai di comportarsi in un altro. Tenere traccia dello stato e generare eccezioni se viene utilizzato un metodo / membro mentre non si trova in un determinato stato sembra fragile e troppo lavoro. Qualche suggerimento basato su come hai risolto questo problema prima? Ed è quello che sto cercando di fare eccessivo? Se il lavoro sta

Answer 1

La tua idea di creare un singolo lavoro di classe base con 3 classi derivate suona esattamente come farei anch'io. La creazione di una JabFactory potrebbe aiutare ulteriormente questo progetto. Potrebbe essere una cattiva pratica creare un oggetto in cui parti dell'oggetto non vengono utilizzate o illegali da utilizzare in determinate circostanze. Quindi creare le classi derivate con solo le parti necessarie è chiaramente il miglior design. Non è eccessivo.