Il documento discute l'importanza di realizzare applicazioni estendibili e configurabili, evidenziando concetti come il principio open-closed e la responsabilità singola. Viene presentata una serie di best practice e design pattern, insieme a strategie per l'inversione di controllo e la gestione delle dipendenze. La necessità di rifattorizzazione continua e la previsione delle variazioni future è enfatizzata per mantenere l'estensibilità del software.

1. Realizzare applicazioni
estendibili e configurabili
Ambizioso?
Mauro Servienti
Microsoft MVP - Visual C#
Software Mason @ Managed Designs S.r.l.
mauro.servienti@manageddesigns.it

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;

6. Un primo approccio al problema
LE DIPENDENZE STATICHE

7. il problema: le dipendenze statiche
Componente Componente
ComA ComB

8. Il cammino verso la soluzione...
Componente Interfaccia
ComA IComB
Componente
ComB
...to be continued

9. Fobia da “dipendenza statica”?, un faro nella nebbia...
I PRINCIPI GUIDA

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”;

12. Non “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;

14. Troppe responsabilità

15. Il panico da “Empty Solution”
BEST PRACTICE(S)

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;

18. Il meglio dei due mondi (1)

19. Il meglio dei due mondi (2)
...to be continued

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”

21. Mascheriamo

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

26. Le “pipeline” (code)

27. Inversion of Control
Interfaccia
Componente
ServiceProvider
ComA (IoC Container) IComB
Componente IoC
ComB Config

28. Vediamolo in azione....
DEMO

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”...?

31. Vediamolo in azione....
DEMO

32. IoC Containers: cosa offrono
• Contenitore di Servizi;
• Lifecycle management;
• Policy Injection (interceptors);
• Difetti? Si la gestione della
configurazione...

33. Non sparate sul pianista....
DOMANDE?

34. Grazie a tutti, mi raccomando...
IL MODULO DI FEEDBACK