2. Agenda
• Perchè?
• Il “problema”;
• Dogmi:
– Open Closed Principle;
– Single Point of Responsability;
• Best Practice(s);
• Inversion Of Control;
• Chain Of Responsability;
• Una voce fuori dal coro: System.AddIn;
3. IMHO
• La bacchetta magica non esiste:
– Ogni volta è una nuova avventura;
– Non c’è una ricetta che vada bene per tutte le
salse ;-)
– Esistono i Design Pattern....ma...
• Partire dai Pattern è rischioso:
– Rischia di farci perdere la visione concreta del
progetto;
– Refactoring to Pattern: “software mason”;
4. Perchè abbiamo bisogno di realizzare applicazioni estensibili.
ESTENSIBILITÀ... WHO
CARES?
5. Perchè?
• Supporto per l’integrazione e
l’interoperabilità;
• Consente di modificare a caldo il
comportamento;
• Elevatissima manutenibilità;
• Verticalizzazione;
• Testing;
• Può essere un’ottimo “strumento”
commerciale;
10. Open Closed Principle
“software entities should be open for
extension, but closed for
modification”
• Open for Extension:
– Il componente deve essere estendibile;
• Closed for Modification:
– L’estensione non deve portare ad una
rottura del rapporto;
11. Ma in soldoni?
• Quello che vogliamo evitare è che
una semplice modifica in un punto si
propaghi a macchi d’olio in tutta
l’applicazione;
– Eg: sostituibilità a “caldo” del DAL
• Se abbiamo un riferimento al DAL concreto
non siamo “Closed”;
• Se facciamo assunzioni particolari non siamo
“Closed”;
13. Single Point of Responsability
• Ad ognuno il suo ruolo;
• Lo scope del ruolo assegnato deve
essere il più preciso possibile
(focuse);
• Se ad un componente assegno più
responsabilità violo l’Open Closed
Principle;
16. Scrivere in ottica estensibilità
• Interfaces vs. Abstract classes;
• Pensare agli entry point;
• Prevedere quali dati potranno essere
necessari;
• Le “pipeline”, un esempio da seguire:
– HttpModule, HttpHanlder;
• Refactoring, refactoring, refactoring,
refactoring e ancora refactoring;
17. Interfaces vs. Abstract classes
Interface Abstract Class
• Posso simulare • Mi permette di fornire
ereditarietà multipla; un’implementazione di
• Non “brucio” l’unico punto base alle classi derivate;
di inheritance
Quindi?
• Colgo il meglio dei due mondi:
• Interface verso il chiamante;
• Abstract Class(es) nel modello;
20. Entry Point
• Dove avrò bisogno di estendere:
– Ovunque ;-), mai chiudersi le porte...
• Un esempio: la “Conversazione”
– è la Session? Si;
– Perchè non usare la Session? E se
domani mattina la Session non mi
andasse più bene?
– Mettiamo le mani avanti: “Facade”
22. ...ma dietro le quinte?
• Slega il nostro modello da Asp.Net;
– Siamo “Open”!;
• Quanto abbiamo investito?
23. Prevedere...
• Non abbiamo la sfera di cristallo
• Incapsulare i dati in classi adatte al
loro trasporto:
– EventArgs;
– CancelEventArgs;
– CustomEventArgs : estendiamo
CancelEventArgs/EventArgs
24. “Trasportare” i dati
• le informazioni non sono sufficienti
• ...non compila più: non siamo “Closed”
25. Le “pipeline”
• “pipeline”, un esempio da seguire:
– HttpModule + HttpHanlder;
Request IProcessor IProcessor IProcessor IProcessor
A B C n
Data
29. IoC Containers e non solo
• StructureMap;
• Castle Windsor;
• Spring.NET
• Unity (Enterprise Library 4.0)
30. I’ve got the power <cit.>
• Se volessimo cambiare l’ordine...?
• Se volessimo aggiungere/rimuovere
step...?
• Se volessimo fare il tutto “a caldo”...?
32. IoC Containers: cosa offrono
• Contenitore di Servizi;
• Lifecycle management;
• Policy Injection (interceptors);
• Difetti? Si la gestione della
configurazione...