Pattern decorativo o modello di strategia

Question

Pattern decorativo o modello di strategia

#1 da (6 voti)

2

Sto costruendo un'applicazione c # serveride e sto cercando di farlo in un modo che possa essere facilmente mantenuto anche esteso se necessario.

Quindi quello che abbiamo sono 4 richieste diverse che devono essere fatte (SOAP, HTTPREQUEST e così via). Questi devono poi essere combinati con una serie di azioni diverse come Importazione / Esportazione / Aggiornamento.

Quello che penso è che ogni richiesta dovrebbe essere una strategia, proprio come la descrizione degli algoritmi di commutazione per il modello di strategia. Quindi voglio estendere la strategia con un decoratore, aggiungendo nuove funzionalità alla richiesta. È necessario contenere questo in una classe separata (SoapRequest_Import / HTTPRequest_Update) o come dovrei pensare? L'ultimo a contenere tutto in una classe sembra togliere la flessibilità?

Quindi, detto questo, sbaglio? Prima domanda, questo è fatto meglio con ciascuno dei modelli o va bene combinarli. Stavo pensando strategie per i diversi clienti e decoratori per i comandi (o funzionalità aggiunte). O sto solo esagerando con questo?

Infine come sembrerebbe codewise se li combinassi. Capisco che ho bisogno di almeno un'interfaccia per i decoratori. Ne ho bisogno anche per le strategie?

c# design-patterns strategy decorator

posta 8bitcat 11.03.2015 - 00:15

fonte

1 risposta

Leggi altre domande sui tag c# design-patterns strategy decorator

Come faccio a progettare correttamente un sistema di contabilità molti-a-molti (spese / pagamenti)? Come dovrei menzionare quei siti in portfolio che sono cambiati da quando ci ho lavorato?

score 6 · Accepted Answer

Smetti di pensare in termini di modelli specifici. Almeno smettere di cercare luoghi per applicare modelli. Inizia a pensare in termini di separazione delle preoccupazioni, e se questo ti riporta a un modello, così sia.

Hai due diversi gruppi di preoccupazioni lì. Le interfacce di comunicazione (Http, Soap, ecc.) E le interfacce dati (Import, Export, Update, ecc.). Il tuo obiettivo dovrebbe essere quello di separare queste preoccupazioni il più completamente possibile.

Cioè, immagina di aver bisogno di aggiungere altri 100 protocolli di comunicazione e altre 100 azioni di dati. Sarebbe meglio se potessi farlo scrivendo altre 200 classi o ti aspetteresti di dover scrivere 10.000 classi? Se stai rispondendo a "10.000", allora stai pensando a tutto sbagliato.

Quindi ciò di cui hai bisogno è un framework che colleghi tutto insieme. Prendi messaggi da un qualche tipo di protocollo di comunicazione, senza sapere quale protocollo e instradare questi messaggi in azioni che scrivono su un'origine dati, senza sapere mai da dove viene il messaggio o perché è stato inviato a questa azione.

Ora, allunga un po 'la tua mente e questo inizia a sembrare un problema che è già stato risolto.

Origine dati = Modello
Protocolli di comunicazione = Visualizza
Azioni = Controller
Routing = well ... routing

Dai un'occhiata ai framework MVC. Uno di questi potrebbe soddisfare tutte le tue esigenze o almeno consentirti di estendere la struttura in base alle tue esigenze. Altrimenti, guarda i pattern usati da un framework esistente, guarda cosa puoi imparare e riapplicalo nel tuo framework.

In alcuni posti, sono sicuro, riconoscerai tutti i tipi di pattern GoF. Sono certo che ci saranno adattatori, fabbriche, forse strategie. Ma il problema generale che stai tentando di risolvere è un problema che MVC risolve almeno in parte (ad esempio, puoi indirizzare le richieste di pagine Web e le richieste Json agli stessi metodi in un controller).

Quindi sarebbe probabilmente un buon posto per iniziare la ricerca. Ma, alla fine, il problema che stai cercando di risolvere è la separazione delle preoccupazioni, in modo che l'estensione di una preoccupazione non influenzi pesantemente il codice esistente nell'altra preoccupazione.

Quindi tienilo a mente per tutto.