[C# - VS2005]Menu riusabile ed eventi buttons

[fek]

Originariamente inviato da ReaToMe

...dove codice riusabile è riferito per lo più a sotto-sistemi.
Creare classi riusabili come quella del topic, non è una perdita di tempo.
In fondo si tratta essenzialmente di un control custom.

Invece e' quasi sempre una perdita di tempo
Perche' per rendere qualcosa riutilizzabile devi renderlo piu' generico, e rendere qualcosa piu' generico vuol dire sempre introdurre piu' complessita', e piu' complessita' vuol dire costi maggiori di manutenzione.

Ricorda che ogni singola riga di codice che scrivi e' una riga di codice che in futuro dovrai mantenere. Magari se scrivi qualche migliaia di righe di codice non cambia molto, ma se ne scrivi centinaia di migliaia in una code base di milioni di righe di codice, vedi che i costi di manutenzione diventano enormi.

E inizi a togliere codice ovunque puoi.

[RaouL_BennetH]

Inoltre, uno degli scopi che stavo cercando di prefiggermi era anche perdere meno tempo in un altro senso:

Quello che trovo più noioso ogni volta è dover disegnare textbox e label sui form per l'interfacciamento con il database. Stavo cercando di realizzare qualcosa che mi permettesse di recuperare i nomi delle colonne dalla tabella del database e fare in modo di disegnare automaticamente tante caselle di testo per quante colonne ci sono nella tabella. Questo, credo, mi farebbe davvero risparmiare una cifra di tempo.

Tutto ciò in linea teorica... perchè in pratica ancora non sono riuscito a farlo.

[RaouL_BennetH]

@isAlreadyInUse:

Ho appena scaricato il tuo esempio. Lo guardo e ti dico. Nel frattempo grazie mille anche a te

Situation....:

Ho capito l'esempio fornitomi da ReaToMe, almeno per quanto riguarda gli eventi relativi al Form in cui viene caricato il menu.

Ora ho un altro problema:

Prendiamo il bottone "Nuovo" e immaginiamo questa situazione:

Sul form c'è un groupbox che contiene diversi oggetti come textbox, combobox etc... che per default all'avvio (load) del form sono disabilitati.

Il tasto "Nuovo" dovrebbe limitarsi a predisporre l'inserimento dei dati, quindi, abilitarmi tutti gli oggetti presenti nel groupbox.

Fino a ieri, io usavo qualcosa del genere:

public void EnableUserInput(Control c)
{
    foreach(Control cc in c.Controls)
    {
        if(cc is GroupBox)
        {
           GroupBox gp = cc as GroupBox;
           gp.Enabled = true;
        }
     }
}

E questo mi permetteva di abilitare all'istante tutti gli oggetti presenti nel groupbox in questo modo:

//procedura presente nell'evento click del bottone "Nuovo"
private void ButtonNew_Click(object sender, EventArgs e)
{
   EnableUserInput(myGroupBox);
}

Adesso, nel codice della classe del menu, ho aggiunto l'evento per il menuitem "Nuovo":

void NewMenuItem_Click(object sender, EventArgs e)
{
   //qui dovrei prima identificare se c'è un groupbox in "MyContainer"
   //ho provato così:
   foreach(Control c in MyContainer.Controls)
   {
     if(c is GroupBox)
     {
        GroupBox gp = c as GroupBox;
        gp.Enabled = true;
     }
    }
}

Al click del bottone però, non avviene nulla. Capisco quindi che non riesce ad identificare il groupbox. Nel dubbio, avevo aggiunto anche un MessageBox per cercare di capire se lo identificasse ma non riuscisse ad "interagire", ma il MessageBox resta vuoto.

Grazie ancora per l'aiuto

RaouL.

[ReaToMe]

Originariamente inviato da fek

Invece e' quasi sempre una perdita di tempo
Perche' per rendere qualcosa riutilizzabile devi renderlo piu' generico, e rendere qualcosa piu' generico vuol dire sempre introdurre piu' complessita', e piu' complessita' vuol dire costi maggiori di manutenzione.

Ricorda che ogni singola riga di codice che scrivi e' una riga di codice che in futuro dovrai mantenere. Magari se scrivi qualche migliaia di righe di codice non cambia molto, ma se ne scrivi centinaia di migliaia in una code base di milioni di righe di codice, vedi che i costi di manutenzione diventano enormi.

E inizi a togliere codice ovunque puoi.

Quello che dici cozza con anni di letteratura informatica.
Il riuso del codice fatto bene nasce da una buona aggregazione delle responsabilità e dalla creazione di classi coese.
Che fino a prova contraria sono tra le basi della buona OOP.

Se per la gestione degli eventi usi il Command Pattern adeguatamente, ti ritrovi ad avere un menu di base che copre buona parte dei casi standard.

Eventuali comportamenti 'fuori standard' verranno gestiti con un numero eguale di Command.

Niente di complicato, e in un progetto con <n> form che usano un menu così fatto, ti sei tolto di torno (<n>-1)+<righe di codice del menu>.

In una parola? Modularità.

[ReaToMe]

Originariamente inviato da RaouL_BennetH

@isAlreadyInUse:

Ho appena scaricato il tuo esempio. Lo guardo e ti dico. Nel frattempo grazie mille anche a te

Situation....:

Ho capito l'esempio fornitomi da ReaToMe, almeno per quanto riguarda gli eventi relativi al Form in cui viene caricato il menu.

Ora ho un altro problema:

Prendiamo il bottone "Nuovo" e immaginiamo questa situazione:

Sul form c'è un groupbox che contiene diversi oggetti come textbox, combobox etc... che per default all'avvio (load) del form sono disabilitati.

Il tasto "Nuovo" dovrebbe limitarsi a predisporre l'inserimento dei dati, quindi, abilitarmi tutti gli oggetti presenti nel groupbox.

Fino a ieri, io usavo qualcosa del genere:

public void EnableUserInput(Control c)
{
    foreach(Control cc in c.Controls)
    {
        if(cc is GroupBox)
        {
           GroupBox gp = cc as GroupBox;
           gp.Enabled = true;
        }
     }
}

E questo mi permetteva di abilitare all'istante tutti gli oggetti presenti nel groupbox in questo modo:

//procedura presente nell'evento click del bottone "Nuovo"
private void ButtonNew_Click(object sender, EventArgs e)
{
   EnableUserInput(myGroupBox);
}

Adesso, nel codice della classe del menu, ho aggiunto l'evento per il menuitem "Nuovo":

void NewMenuItem_Click(object sender, EventArgs e)
{
   //qui dovrei prima identificare se c'è un groupbox in "MyContainer"
   //ho provato così:
   foreach(Control c in MyContainer.Controls)
   {
     if(c is GroupBox)
     {
        GroupBox gp = c as GroupBox;
        gp.Enabled = true;
     }
    }
}

Al click del bottone però, non avviene nulla. Capisco quindi che non riesce ad identificare il groupbox. Nel dubbio, avevo aggiunto anche un MessageBox per cercare di capire se lo identificasse ma non riuscisse ad "interagire", ma il MessageBox resta vuoto.

Grazie ancora per l'aiuto

RaouL.

Hai aggiunto l'handler?

this.AddNewButton("NewMenuItem", "&Nuovo",  NewMenuItem_Click);

[fek]

Originariamente inviato da ReaToMe

Quello che dici cozza con anni di letteratura informatica.
Il riuso del codice fatto bene nasce da una buona aggregazione delle responsabilità e dalla creazione di classi coese.
Che fino a prova contraria sono tra le basi della buona OOP.

Ma quello che dico si sposa con i dati sperimentali e le analisi di costo del software, che e' l'unica cosa che conta.
E' provato che scrivere software riutilizzabile costa il 30% in piu' e quel costo raramente, in pratica, viene amortizzato.

Se per la gestione degli eventi usi il Command Pattern adeguatamente, ti ritrovi ad avere un menu di base che copre buona parte dei casi standard.

E che ogni volta devi adattare al caso particolare dove molto probabilmente una soluzione piu' semplice sarebbe stata perfettamente adeguata allo scopo e costa molto meno da mantenere. Perche' scrivere il codice ha un costo, ma mantenerlo e supportarlo ha un costo maggiore.

La teoria che insegnano all'Universita' va molto bene per qualche progettino di piccole dimensioni, ma quando ti ritrovi a lavorare con code base di milioni di righe di codice, come ho detto, ti accorgi che forse e' molto meglio smettere di overingegnerizzare ed e' molto meglio iniziare a scrivere codice semplice e facile da mantenere. Perche' nove volte su dieci You Ain't Gonna Need It.

C'e' sempre tempo per rifattorizzare e estrarre dalla code base codice piu' generico che puo' essere riutilizzato.

In una parola? Modularità.

In una parola? Keep It Simple, Sweety (Sono quattro parole )

[ReaToMe]

Originariamente inviato da fek

Ma quello che dico si sposa con i dati sperimentali e le analisi di costo del software, che e' l'unica cosa che conta.
E' provato che scrivere software riutilizzabile costa il 30% in piu' e quel costo raramente, in pratica, viene amortizzato.

Potrei tirare fuori altrettanti dati sperimentali che sostengono l'esatto contrario.

Originariamente inviato da fek

E che ogni volta devi adattare al caso particolare dove molto probabilmente una soluzione piu' semplice sarebbe stata perfettamente adeguata allo scopo e costa molto meno da mantenere. Perche' scrivere il codice ha un costo, ma mantenerlo e supportarlo ha un costo maggiore.

Con conseguente copia/incolla del codice, rindondanza e 2x di linee di codice da mantenere.
Per questi casi c'è una stupidata dell'OOP chiamata ereditarietà...

Originariamente inviato da fek

La teoria che insegnano all'Universita' va molto bene per qualche progettino di piccole dimensioni, ma quando ti ritrovi a lavorare con code base di milioni di righe di codice, come ho detto, ti accorgi che forse e' molto meglio smettere di overingegnerizzare ed e' molto meglio iniziare a scrivere codice semplice e facile da mantenere. Perche' nove volte su dieci You Ain't Gonna Need It.

Quindi l'ultimo framework che ho fatto per la mia azienda lo devo buttare al cesso. Mannaggia.
C'è un limite ben delineato tra ingegnerizzazione e overingegnerizzare.
Sicuramente overingegnerizzare non è sinonimo di riusabilità.

Originariamente inviato da fek

C'e' sempre tempo per rifattorizzare e estrarre dalla code base codice piu' generico che puo' essere riutilizzato.

Da quello che dici mi dai l'idea di avere un approccio un po' procedurale all'OOP.

Originariamente inviato da fek

In una parola? Keep It Simple, Sweety (Sono quattro parole )

Troppe. 4 volte la mia.

Il codice riusabile (se scritto bene) tra i tanti pregi ne ha tre enormi:
1) Riduce il numero di Code-Line.
2) Localizza le responsabilità e rende le classi coese.
3) Evita la rindondanza.

Se poi questo per te può essere causa di overhead nella manutenzione...

PS
Non mi ricordo manco come è fatta un'università

[fek]

Originariamente inviato da ReaToMe

Potrei tirare fuori altrettanti dati sperimentali che sostengono l'esatto contrario.

Fallo.

Con conseguente copia/incolla del codice, rindondanza e 2x di linee di codice da mantenere.
Per questi casi c'è una stupidata dell'OOP chiamata ereditarietà...

A parte "Prefer Composition Over Inheritance", l'ereditarieta' e' spesso e volentieri una cosa negativa e va usata con parsimonia. Meglio comporre oggetti.
Ma chi ha parlato di ridondanza e duplicazione?
La duplicazione va eliminata al volo, appena si presenta, "Don't Repeate Yourself".

Quindi l'ultimo framework che ho fatto per la mia azienda lo devo buttare al cesso. Mannaggia.
C'è un limite ben delineato tra ingegnerizzazione e overingegnerizzare.
Sicuramente overingegnerizzare non è sinonimo di riusabilità.

Hmmm... Non esistono framework, esistono soluzioni, l'ultimo che qui voleva scrivere un framework per fare il build asset... e' ancora li' la notte che fissa bug.

Da quello che dici mi dai l'idea di avere un approccio un po' procedurale all'OOP.

Io, procedurale?

Troppe. 4 volte la mia.

Ma segnano la differenza fra un buon programmatore e uno che scrive codice.

Il codice riusabile (se scritto bene) tra i tanti pregi ne ha tre enormi:
1) Riduce il numero di Code-Line.
2) Localizza le responsabilità e rende le classi coese.
3) Evita la rindondanza.

Se poi questo per te può essere causa di overhead nella manutenzione...

Si', lo e', perche' e' vero l'esatto contrario. Scrivere constantemente per la riusabilita' (oltre come ho detto a costare il 30% in piu' e non portare benefici), tende ad aumentare le righe di codice da mantenere, perche' significa produrre soluzioni piu' generiche e complesse per essere riutilizzabili, dove una soluzione meno complessa poteva essere perfettamente adeguata. Non evita la ridondanza, anzi, tende a promuoverla perche' tende ad aumentare la complessita'. Non localizza le responsabilita', ma tende ad aumentare la genericita' degli oggetti rendendoli quindi meno coesi e piu' complessi.
Hai mai avuto a che fare con code base di qualche milione di righe di codice?

La mia lotta contro la sovraingegnerizzazione del codice non avra' mai fine...
Keep It Simple, Silly

[ReaToMe]

Mai letti così tanti ossimori in una volta.

[fek]

Originariamente inviato da ReaToMe

Mai letti così tanti ossimori in una volta.

Mostrameli. E spiega il perche' sarebbero ossimori. Ti assicuro che e' molto piu' probabile che ti stia sfuggendo qualche passaggio del mio discorso.

Anzi, apri un bel topic sulla riusabilita' del codice e ti spiego li' per filo e per segno perche' scrivere per riutilzzare il codice (e non il riutilizzo di codice di per se') non e' una buona idea.

[wingman87]

@Raoul: mi sembra che per fare quello che vorresti fare (piazzare i controlli in base alle colonne che hai nelle tabelle del db) c'è un modo semplice di farlo con l'IDE, io almeno l'avevo fatto con VB (sempre il .NET) quindi immagino si possa fare anche in C#, ora però non saprei dirti di più ma sicuramente su internet trovi qualcosa al riguardo...

[ReaToMe]

Originariamente inviato da fek

Mostrameli. E spiega il perche' sarebbero ossimori. Ti assicuro che e' molto piu' probabile che ti stia sfuggendo qualche passaggio del mio discorso.

Sempre IMHO naturalmente.
Ho espresso la mia opinione, nuda e cruda.
Per quanto mi riguarda quel che dici fa' a pugni con la mia esperienza lavorativa.
Avere una archittettura semplice e allo stesso tempo riusabile per me non è assolutamente difficile.
Semplicemente è la mia realtà quotidiana.
E non ho bisogno di fare un lavoro di affinamento successivo (che ha un costo) per ottenere classi, sottosistemi o sistemi riusabili.
Ho avuto a che fare con progetti di svariate dimensioni.
Ed ho sempre applicato queste regole.
Non credo che l'ereditarietà sia superiore alla composizione o viceversa, vanno a braccetto.
La complessità di certe soluzioni riusabili nasce non tanto dalle linee di codice, ma tanto dal maggior livello di collaborazione che si instaura tra gli oggetti, che viene ripagata da una maggiore area di copertura del dominio.
Rindondanza e complessità non sono collegabili.
Sviluppare senza un occhio alla riusabilità porta ad avere parti di codice ripetute. E questa è rindondanza. Che comporta per una singola modifica, n interventi pressochè identici.
Rendere una classe riusabile non significa renderla meno coesa.
Ammesso che uno non ci infili tutto quello che gli passa per la testa.
Ti sembra che la classe postata prima sia poco coesa? Eppure è riusabile.
C'è chi la complessità la spalma nella classe, e chi la gestisce facendo collaborare le classi tra loro. O se preferisci OOP.

[fek]

Originariamente inviato da ReaToMe

Sempre IMHO naturalmente.
Ho espresso la mia opinione, nuda e cruda.
Per quanto mi riguarda quel che dici fa' a pugni con la mia esperienza lavorativa.
Avere una archittettura semplice e allo stesso tempo riusabile per me non è assolutamente difficile.
Semplicemente è la mia realtà quotidiana.
E non ho bisogno di fare un lavoro di affinamento successivo (che ha un costo) per ottenere classi, sottosistemi o sistemi riusabili.

Stai cercando di convincermi che tu hai un problema, e sei in grado di scrivere una soluzione perfetta, riutilizzabile e che non necessita' ne' affinamenti ne' refactoring al primo colpo?
Se e' davvero cosi', ti prego, spiegami come fai, scriviamo un libro e ci facciamo i milioni.
Perche' non c'e' riuscito ancora nessuno al mondo

Avere un'architettura semplice e riusabile e' impossibile, sono due obiettivi che remano uno contro l'altro per definizione di "riusabilita'", ovvero qualcosa che puo' essere riusato in progetti diversi con finalita' diverse, ovvero generico. La genericita' ha sempre un costo in termini di complessita'.

Non credo che l'ereditarietà sia superiore alla composizione o viceversa, vanno a braccetto.

Credi male, perche' una classe che eredita da un'altra ha un valore di coupling maggiore rispetto alla stessa classe in composizione con l'altra. E' dimostrato che valori di coupling piu' alti, statisticamente, generano piu' difetti. Dunque, dove la composizione risolve il problema, e' sempre preferibile all'ereditarieta'.

Sviluppare senza un occhio alla riusabilità porta ad avere parti di codice ripetute. E questa è rindondanza. Che comporta per una singola modifica, n interventi pressochè identici.

Falso. Scrivo centinaia di migliaia di linee di codice l'anno, non scrivo NULLA per essere riusato (perche' mi costa il 30% in piu', te lo ricordo, e ancora non mi hai portato controesempi), eppure e' difficile trovare mio codice duplicato. Diciamo impossibile: rifattorizzo in continuazione.

Rendere una classe riusabile non significa renderla meno coesa.
Ammesso che uno non ci infili tutto quello che gli passa per la testa.
Ti sembra che la classe postata prima sia poco coesa? Eppure è riusabile.
C'è chi la complessità la spalma nella classe, e chi la gestisce facendo collaborare le classi tra loro. O se preferisci OOP.

Tutto e' per definizione riusabile, il problema non e' questo. Il problema e' quanto costa riusarlo e, come ho detto, costa piu' che scrivere il codice piu' semplice possibile che risolve il problema. Si chiama pragmatismo. O saper programmare (in OOP)

PS. Citi spesso l'OOP, ma ti assicuro che "Prefer Composition Over Inheritance" e' uno dei concetti base della programmazione orientata ad oggetti (cfr Design Patterns, Gang Of Four).

Apri un topic, continuiamo li'.

[ReaToMe]

Originariamente inviato da fek

Stai cercando di convincermi che tu hai un problema, e sei in grado di scrivere una soluzione perfetta, riutilizzabile e che non necessita' ne' affinamenti ne' refactoring al primo colpo?
Se e' davvero cosi', ti prego, spiegami come fai, scriviamo un libro e ci facciamo i milioni.
Perche' non c'e' riuscito ancora nessuno al mondo

Avere un'architettura semplice e riusabile e' impossibile, sono due obiettivi che remano uno contro l'altro per definizione di "riusabilita'", ovvero qualcosa che puo' essere riusato in progetti diversi con finalita' diverse, ovvero generico. La genericita' ha sempre un costo in termini di complessita'.



Credi male, perche' una classe che eredita da un'altra ha un valore di coupling maggiore rispetto alla stessa classe in composizione con l'altra. E' dimostrato che valori di coupling piu' alti, statisticamente, generano piu' difetti. Dunque, dove la composizione risolve il problema, e' sempre preferibile all'ereditarieta'.



Falso. Scrivo centinaia di migliaia di linee di codice l'anno, non scrivo NULLA per essere riusato (perche' mi costa il 30% in piu', te lo ricordo, e ancora non mi hai portato controesempi), eppure e' difficile trovare mio codice duplicato. Diciamo impossibile: rifattorizzo in continuazione.



Tutto e' per definizione riusabile, il problema non e' questo. Il problema e' quanto costa riusarlo e, come ho detto, costa piu' che scrivere il codice piu' semplice possibile che risolve il problema. Si chiama pragmatismo. O saper programmare (in OOP)

PS. Citi spesso l'OOP, ma ti assicuro che "Prefer Composition Over Inheritance" e' uno dei concetti base della programmazione orientata ad oggetti (cfr Design Patterns, Gang Of Four).

Apri un topic, continuiamo li'.

Ti suggerirei di leggere il sottotitolo del libro che hai citato...

[fek]

Originariamente inviato da ReaToMe

Ti suggerirei di leggere il sottotitolo del libro che hai citato...

Conosco quel libro a memoria e non solo quello

[ReaToMe]

Non sei il solo.
Per dovere di cronaca il titolo completo è
"Design Patterns: Elements of Reusable Object-Oriented Software"

[fek]

Originariamente inviato da ReaToMe

Non sei il solo.
Per dovere di cronaca il titolo completo è
"Design Patterns: Elements of Reusable Object-Oriented Software"

E quindi?
Se tu avessi compreso il libro, non avresti fatto questa sterile puntualizzazione, perche' sapresti che da nessuna parte la Gang Of Four afferma che il codice deve essere scritto riutilizzabile, ma presenta design che possono essere riutilizzati nella progettazione del software. Sono due concetti estremamente differenti.
Infatti e' profondamente sbagliato pensare di "programmare a design pattern". Tanto e' vero che i design pattern oggi sono usati come uno strumento di documentazione e descrizione del codice, e non piu' come uno strumento di design.

Ora, puoi mostrarmi dove sarebbero i miei ossimori e puoi rispondere alle numerose puntalizzazioni che ho fatto? O pensi ancora che Ereditarieta' e Composizione siano sullo stesso piano? Mi porteresti anche questi numerosi esempi contrari al mio che mostra come scrivere codice riutilizzabile sia piu' costoso? Ti ringrazio.

[ReaToMe]

Ti basterebbe leggere con attenzione il paragrafo seguente all'enunciazione del principio che hai citato sopra.

Vuoi dire che tu sviluppi senza handler, listener, command, decorator, factory o singleton?
E che non scrivi sempre con una struttura similare?
E che non hai mai consolidato una soluzione per un problema che ti si ripresenta sistematicamente?

Hai le tue convinzioni, ed evidentemente portano frutto al tuo lavoro.
Io ho le mie e come tu con le tue, me le tengo strette.

[fek]

Originariamente inviato da ReaToMe

Ti basterebbe leggere con attenzione il paragrafo seguente all'enunciazione del principio che hai citato sopra.

Ho letto tutto con estrema attenzione.

Vuoi dire che tu sviluppi senza handler, listener, command, decorator, factory o singleton?
E che non scrivi sempre con una struttura similare?
E che non hai mai consolidato una soluzione per un problema che ti si ripresenta sistematicamente?

Ma dove ho mai scritto che sviluppo senza usare design pattern? Li uso, e in abbondanza. Emergono costantemente dal codice che scrivo. Stai facendo tantissima confusione, mi sembra che neppure ti sforzi di capire cio' che sto scrivendo, per partito preso.

Io non sono contro il riutilizzo del codice (l'esatto contrario).
Io non sono contro i Design Pattern (al contrario, un programmatore che non li recita a memoria per me non andrebbe neppure assunto).

Io sono contro la sovraingegnerizzazione e la scrittura del codice con lo scopo di riutilizzarlo, perche' sono pratiche di sviluppo inadeguate e inefficienti.

Hai le tue convinzioni, ed evidentemente portano frutto al tuo lavoro.
Io ho le mie e come tu con le tue, me le tengo strette.

Io non ho alcuna convinzione, mi limito a seguire buone pratiche di sviluppo che sono ampiamente dimostrate produttive, infatti ancora non mi hai portato quei numerosi studi che secondo te dimostrerebbero il contrario...
Io seguivo cio' che tu stai predicando qui dieci anni fa. Poi mi sono trovato di fronte a code base di milioni di righe di codice, lavorando con cinquanta ingegneri, per fortuna non ho avuto la presunzione di tenermi strette le mie convinzioni di allora, ed ho imparato a programmare finalmente e la mia produttivita' e' aumentata.

PS. Si', sviluppo sempre senza Singleton

[ReaToMe]

Originariamente inviato da fek

Considerala una fesseria
Il CoCoMo model (nome stupidissimo per altro) per la stima del costo del software ha calcolato che scrivere codice per essere riusabile costa mediamente il 30% in piu' (in termini di tempo e denaro) e solo il 10% delle volte e' effettivamente riutilizzato. In pratica, scrivendo codice riutilizzabile paghi in termini di tempo e complessita' della soluzione senza ricevere nulla in cambio nella maggior parte dei casi.

Quale studio?
Quali costi sono stati presi in considerazione?
Con quali processi di sviluppo?

Prova a scrivere su google "oo reusability cost study"

Originariamente inviato da fek

E quindi?
Infatti e' profondamente sbagliato pensare di "programmare a design pattern". Tanto e' vero che i design pattern oggi sono usati come uno strumento di documentazione e descrizione del codice, e non piu' come uno strumento di design.

Se mi scrivi questo io penso che tu non gli usi...