Quali ritieni siano gli schemi di progettazione essenziali? E li usi? [chiuso]

Modelli di design Lontano come vanno i modelli di progettazione, io lavoro in un ambiente in cui ci sono molte dipendenze tra i componenti, quindi il modello adattatore viene utile. Soprattutto quando si tenta di introdurre cuciture nel codice per il supporto al test dell'unità. L'idea è che tu crei un wrapper su un'interfaccia di terze parti (per quanto riguarda il tuo codice) su cui si basa il tuo codice e che il wrapper è responsabile della traduzione delle richieste del tuo codice in qualsiasi cosa l'API di terze parti desideri.

Vedo anche Factory utilizzato dove dobbiamo fornire modi per istanziare gli oggetti definiti nel codice dell'infrastruttura di supporto da i suoi consumatori.

Modelli architettonici
La tua domanda, tuttavia, parla anche di diverse architetture come MVC e MVVM. Non ho usato MVVM da solo, ma sono davvero due lati della stessa moneta. Non importa se utilizzi MVC, MVVM, MVP o qualsiasi altra cosa: separare i tuoi problemi di interfaccia utente dalla tua logica aziendale e dall'accesso ai dati (se esiste) è una buona idea. Non lavoro più sull'interfaccia utente, ma quando l'ho fatto, ho passato un bel po 'di tempo a fare proprio questo.

(Si noti che ASP.NET MVC è un framework su se stesso. Fa uso dell'approccio MVC, ma fai attenzione quando lo si riferisce semplicemente come "MVC". È possibile e probabilmente verrà frainteso e le persone andranno "cosa smart URL? ")

Principi di progettazione
Oltre a questo, sono un grande fan di i principi SOLID :

• Principio di responsabilità singola - un oggetto dovrebbe avere una sola responsabilità
• Principio aperto / chiuso : le entità devono essere aperte per l'estensione e chiuse per la modifica. In altre parole, dovresti essere in grado di estendere il comportamento di una classe senza dover modificare il suo codice.
• Principio di sostituzione di Liskov - le sottoclassi dovrebbero essere utilizzabili al posto di una classe base senza che il consumatore se ne accorga
• Principio di segregazione dell'interfaccia - espone solo le cose di cui il cliente ha bisogno. Molte piccole interfacce specializzate sono migliori di una generica generica.
• Principio di inversione delle dipendenze - dipende dalle astrazioni, non dalle concrezioni.

Li uso tutti quanti il più possibile. Ci sono buoni video introduttivi per ogni principio su Dimecasts .

E ora qualcosa di un po 'diverso ... Detto questo, penso che ti stai avvicinando da questa direzione sbagliata. Mentre solo alcuni schemi e approcci sono popolari, penso che sia importante apprenderne quanti ne puoi a prescindere dalla loro popolarità. Direi sicuramente che dovresti imparare (almeno a livello base) ogni schema che incontri. Non sai mai quando un pattern oscuro può semplificarti la vita. Puoi sempre andare più nel dettaglio e imparare un modello in profondità quando ne hai bisogno ... ma non sai quando è necessario a meno che tu non sappia che esiste affatto e hai una vaga idea di cosa si tratta.

Dai un'occhiata alla matrice delle competenze dei programmatori , guarda dove sei e questo ti darà un percorso leggermente meno fangoso per il miglioramento complessivo di uno sviluppatore.

Questo articolo di msdn menziona esplicitamente schemi di progettazione nel .net framework .

Ad esempio, cita schemi considerati abbastanza essenziali da essere integrati nel linguaggio come osservatore e iteratore. L'osservatore è supportato da eventi e delegati. Foreach è un modo in cui è supportato l'iteratore.

Un altro esempio menzionato è il pattern di decoratore utilizzato nella libreria del flusso. La classe BufferedStream può decorare un flusso di memoria per fornire il comportamento aggiuntivo di leggere blocchi di dati alla volta.

L'articolo descrive un modello di strategia utilizzato nell'Elenco quando si implementa un algoritmo di confronto e lo si passa a List.Sort. L'ho usato occasionalmente.

Un quinto modello menzionato è il metodo di fabbrica. Un esempio è la classe Convert. La classe Convert ha alcuni metodi statici che restituiscono le classi, ad esempio Convert.ToDateTime.

link - è una lista abbastanza buona. Non direi che è molto.

Scegliere quale schema di progettazione ricorderai è come scegliere se portare con te un martello o un cacciavite. Non si sostituiscono a vicenda, si completano a vicenda.

Steve Smith ha avuto un eccellente video podcast su dnrTV su schemi di progettazione comunemente usati (1 ora e 4 minuti) . Copre i seguenti modelli comuni:

• Singleton (chiamato come anti-pattern che vuoi evitare)
• Strategia
• Repository
• Proxy
• Comando
• Fabbrica

Ho trovato il video molto interessante e un'ottima panoramica degli schemi più comuni. Per una guida di studio più approfondita per la programmazione potresti voler dare un'occhiata a di Scott Hanselman. Che cosa dovrebbero sapere i grandi sviluppatori .NET. (Altro. NET Interview Questions) e più recenti Nuove domande di intervista per Senior Software Engineers post del blog.

DakotahNorth lo menziona sopra in un commento, ma per capire gli schemi devi tornare ai fondamenti. Lei menziona alcuni schemi belli / essenziali nella sua domanda (MVVM, MVC, ecc.), Ma sono costruiti attorno a molti dei modelli fondamentali descritti nel libro Gof. Sicuramente la Bibbia e l'inizio di qualsiasi studio di modelli.

Quelli che usiamo ogni giorno?

Che ne dici di Observer - ogni volta che colleghiamo un evento o Fabbrica - ogni volta che usi un contenitore Ioc o cose come strategia o bridge - quando si mettono in relazione e si legano regole di business e comportamenti comuni.

Direi che il "più" essenziale dalla mia testa è:

Repository (o analogo livello di astrazione dei dati, ad esempio TableDataGateway, DAO, ecc.)

PERCHÉ: l'astrazione del livello dati è una cosa buona . Anche se non hai intenzione di cambiare server o piattaforme di database, avere una sorta di wrapper attorno alle chiamate del database di base (ad esempio SqlCommand e amici) e restituire oggetti business reali (invece di restituire un DataSet ) rende il tuo codice è più pulito e più facile da seguire. È dieci volte più facile leggere qualcosa del tipo:

IList<Customer> recentCustomers = CustomerRepository.GetRecentCustomers();
foreach (Customer customer in recentCustomers)
{
    string name = customer.Name;
    // other things here...
}

di questo:

DataSet recentCustomers = SqlHelper.ExecuteDataset(sqlCommand);
if (recentCustomers.Tables[0].Rows.Count > 0) 
{ 
    for (int i = 0; i < recentCustomers.Tables[0].Rows.Count; i++) 
    { 
        string name = recentCustomers.Tables[0].Rows[i]["CustName"].ToString();
        // other stuff here...
    }
}

Anche se non stai seguendo DDD con Entities e Value Objects, e la versione DDD di un repository (sto usando il termine in modo più generico), usare un pattern come questo è la chiave per avere un buon design .

C'è un argomento da fare per qualsiasi modello per essere un favorito.

Il mio preferito recente sta utilizzando il modello di messaggistica, in cui si mantengono i componenti altamente disaccoppiati e si inviano messaggi reciproci. Questo si combina bene con l'iniezione delle dipendenze (come il modello dell'interfaccia).

Un altro preferito recente è il modello di builder. Nella costruzione di una struttura dati complessa e flessibile, è utile limitare la costruzione e semplificare enormemente il processo. Ad esempio, costruendo un FlowDocument vincolato o generando dinamicamente una query.

Ma questi sono solo i miei preferiti perché sto lavorando sul codice che li utilizza. Sono sicuro che il mio prossimo sottoprogetto utilizzerà altri schemi che mi fanno sorridere.

In realtà non uso schemi di progettazione, a meno che non sia chiaro al 100% ne ho bisogno uno che si adatti. Ciò significa che non controllo per ogni problema: esiste un modello di progettazione? Ma lo uso quando noto che la soluzione che ho creato è (simile) a un modello di progettazione o quando incontro un problema per il quale non ho una risposta.

Tendo ad usare il modello di progettazione più semplice, semplicemente perché quanto più semplice, quanto più generico possono essere usati, questi sono:

• Singleton
• facciata (utile per l'interfaccia con gli altri)
• factory astratta (utile nel mio lavoro dal momento che abbiamo molti dispositivi più o meno correlati)
• observer (in C # tipo di incorporato)