Nel implementare una applicazione uso gli oggetti del framework .NET, ovviamente! Per quanto cerchi di applicare DIP (il principio di buon disegno OO chiamato "Dependency Inversion Principle") il framework finisce comunque per avere un ruolo nel facilitarmi o complicarmi l'implementazione delle scelte di disegno che ho fatto.
Questi i due casi in cui ASP.NET mi ha reso complicata o impossibile una buona scelta di disegno OO:
- Cosa? Estrarre delle nuove classi da una classe (ossia fare Refactoring) quando il codice diventa troppo corposo e complicato e parti di codice sono duplicate e fare evoluzioni (togliere bug, aggiungere o cambiare funzionalità) richiede di intervenire a macchia di leopardo su parti del codice apparentemente non correlate.
Chi? I Web User Control .ASCX
Perché? Perché il codice da estrarre fa uso di funzioni di System.Web.UI.UserControl che sono accessibili solo dalla classe derivata (come la property ViewState o il metodo LoadViewState) e non da una diversa classe.
- Cosa? Separare i dati (lo stato della appplicazione e i dati del dominio applicativo) dalla loro presentazione e dal controllo del flusso di interazione utente. Ossia applicare il pattern MVC.
Chi? I WebForm ASP.NET.
Perché? Ad esempio per estrarre responsabilità dalla singola pagina e inserirle in classi diverse è necessario usare funzioni poco conosciute (come usare HttpContext per accedere alla Session da classi che non derivano da Page1) o implementtare funzioni di sistema assenti (come la property CurrentDocument che nella classe System.Uri è privata ma invece è utile per implementare il controllo della navigazione1)
- ...
Lascio ai nostri MVP (che fa rima col pattern MVC) l'onere di informare Microsoft di queste difficoltà avvertite da un programmatore .NET (ma sono il solo??? voi come avete risolto questi casi? fatemi sapere).
Se non posso conoscere i motivi per cui il Team di ASP.NET ha scelto in entrambi i casi (Web Form e Web User Control) di disegnare le cose in questo modo posso invece rilevare che in entrambi i casi le funzioni del framework sono rese disponibili attraverso l'ereditarietà invece che il contenimento (scelta di disegno notoriamente sconsigliabile) e questo potrebbe soffrire del problema della FragileBaseClass.
Bene... dopo questo sfogo posso tornare a lavorare al user control DataTableEditor, dopo aver combattuto duramente col problema al punto 1 mi aspetta un po' di refactoring (per eliminare le smell di 'codice duplicato', 'shotgun surgery' e 'lunghe liste di switch/if ').
---------
(1) Vedi l'esempio scaricabile della sessione Refactoring Applied dal Workshop UGI Architecture & Management