Qual è il modello di design più adatto?

-2

Ho studiato Design Patterns e sto cercando di implementarli nel mio ultimo progetto.

Sto lavorando su un servizio di Windows che controlla regolarmente una tabella di database per una nuova voce. A seconda della voce trovata, il servizio eseguirà un numero di processi.

I processi possibili includono:

1) Genera rapporto e invia e-mail con rapporto allegato

2) Esegui query e registra i dati su un'altra tabella

3) Invia email di notifica

Quale modello di design è più adatto? Ho considerato il modello di fabbrica.

Il mio processo di progettazione finora ...

1) Crea interfaccia

2) Crea una classe astratta che implementa l'interfaccia

3) Metodi astratti:

- CheckTable()
- GenerateReport()
- SendEmail()

4) Modello di progettazione di fabbrica:

- The client(windows service) asks the Factory for a new object (based of the database entry found)
- The factory instantiates this and returns to the client
- The client then calls the relevant methods to send email or run query.

Questo sembra corretto? O lo sto rendendo più difficile di così?

O dovrei usare il modello di osservatore?

UPDATE:

OK. Ho seguito il tuo consiglio e ho cercato il modo più semplice per farlo.

Il sottostante è corretto? Ho creato un'interfaccia e quindi una classe per implementare questa interfaccia.

Potrebbero esserci diversi report / email da generare. Dovrebbero essere aggiunti come nuovi metodi nell'interfaccia?

Ho bisogno di una classe astratta?

// interface
internal interface IJobs
{
    void SendEmail();
    void PublishData();
    void GenerateTestReport(string userID, DateTime period);
}


// concrete class
public sealed class JobsFactory : IJobs
{
    #region SINGLETON

    private static JobsFactory INSTANCE;

    private JobsFactory() { }

    public static JobsFactory GetInstance()
    {
        if (INSTANCE == null)
        {
            INSTANCE = new JobsFactory();
        }
        return INSTANCE;
    }

    #endregion

    private readonly WorkbookFactory _workbookFactory = WorkbookFactory.GetInstance();

    #region IJobs Members

    public void SendEmail()
    {
        // send email
    }

    public void PublishData()
    {
        // publish data
    }

    public void GenerateTestReport(string userID, DateTime period)
    {
        string reportTestFilePath = this._workbookFactory.BuildTestReportWorkbook(userID, period);
    }

    #endregion
}
    
posta K09 12.01.2015 - 12:38
fonte

3 risposte

18

Ti racconterò una storia. Molti anni fa, quando ero un giovane programmatore inesperto e GoF non aveva pubblicato molto tempo prima il loro libro Design Patterns, e Java era un nuovo linguaggio e l'unica libreria di interfaccia utente generalmente disponibile per AWT, e le applicazioni AWT sembravano tutte brutte come diavolo, la mia azienda ha deciso di passare dallo sviluppo C ++ a Java. Ma AWT era fuori questione: le nostre applicazioni dovevano apparire come le app native di Win 32, e con AWT non ci riuscivamo. Quindi, sono stato incaricato di apprendere JNI e implementare un framework che ci permettesse di creare interfacce utente Windows native usando Java.

Non avevo letto molto tempo prima su Design Patterns ed ero ansioso di usarli, quindi ho guardato il mio progetto e ho pensato a quali sarebbero adatti dove. L'idea di cui ero più orgoglioso era questa: avrei avuto un oggetto Window nativo che incapsulava un handle della finestra win32, ma per consentire all'applicazione di collegare i comportamenti alla finestra, userei Chain of Responsibility. Ciò consentirebbe alle applicazioni di utilizzare i comportamenti esistenti e combinarli in modi nuovi, e tutto sarebbe ottimo.

Quindi ho implementato Chain of Responsibility, ed era un po 'più complesso del semplice fatto di avere un singolo oggetto Behavior che gestiva tutto, ma ho scritto una manciata di test che lo utilizzavano e tutto ha funzionato magnificamente.

Poi abbiamo implementato il framework e iniziato a scrivere applicazioni reali usandolo, e sai cosa? Non una volta abbiamo mai usato la funzione per concatenare più comportamenti in un'unica finestra.

La lezione qui è semplice: non iniziare usando il catalogo Design Pattern per acquistare maggiore flessibilità nella tua applicazione. Inizia pensando a quale flessibilità hai davvero bisogno e poi a come puoi implementare quella flessibilità. Potrebbe essere che un modello standard sia il modo migliore per ottenerlo. Potrebbe esserci un modo più semplice e diretto. Può anche darsi che tu abbia un problema rigido, ben definito, abbastanza piccolo da poter progettare l'intera soluzione semplicemente senza bisogno di alcuno scopo per modificare il comportamento in un secondo momento, nel qual caso qualsiasi cosa che si approssima a uno schema di progettazione sarebbe probabilmente eccessivo .

Per prendere in prestito una frase da Kent Beck, "fai la cosa più semplice che possa funzionare". Se ciò accade, finirà per sembrare uno schema, è grandioso. Ma non ti preoccupare se non lo fa.

    
risposta data 12.01.2015 - 13:19
fonte
5

Comincerei appena senza usare modelli.

var records = CheckTable();
foreach(var record in records)
{
    GenerateReport(record);
    SendEmail(record);
}

Inizia semplice, non tutto ha bisogno di un modello. Se inizi a svolgere molte attività diverse, o consenti alle attività di essere configurabili nell'ordine e al numero di attività eseguite per record, pensa a estenderlo tramite il refactoring.

    
risposta data 12.01.2015 - 18:00
fonte
2

Poiché devi eseguire ciò che sembra essere un sondaggio, puoi dare un'occhiata a Observer Pattern . Ciò consentirebbe al tuo servizio di chiamare i tuoi metodi in modo che possano prendere le misure appropriate.

Detto questo, come è stato menzionato nei commenti, sembra che ci siano schemi di design al contrario. Il compito dovrebbe portarti a un modello di progettazione. Cercare di avvolgere le tue esigenze attorno a un particolare modello di design non è il modo migliore per avvicinarti alla progettazione.

    
risposta data 12.01.2015 - 13:03
fonte

Leggi altre domande sui tag