Gli alias di namespace gli definisco nel codice così
using sysDat = System.Data;
using sysSql = System.Data.SqlClient;
using sysXmlSrl = System.Xml.Serialization;
using sysRtmSrl = System.Runtime.Serialization;
e quindi per indicare il tipo DataRow scrivo sysDat.DataRow.
Se invece nel codice scrivo
using System.Data;
posso anche dimenticarmi che esiste il namespace System.Data e per indicare il tipo DataRow scrivo DataRow e basta.
Quando disegno il codice (sia up-front che col refactoring) uso i namespace per organizzare i tipi (classi, enum, etc.) raggruppando quelli logicamente correlati (un EventArgs insieme al suo evento, il tipo Spedizione insieme all'enum TipoSpedizione, etc.) [1]. Quando poi dichiaro, istanzio o referenzio quei tipi, il namespace in cui sono mi aiuta a comprendere la logica con cui sono stati disegnatio e quindi il modo corretto di usarli.
Ecco che l'uso dell'Alias mi costa qualche tasto in più da premere ma mi aiuta a comprendere meglio l'astrazione che il disegno vuole creare [2].
Per esempio nel codice quando leggo sysDat so che l'oggetto indicato di riferisce alla rappresentazione relazionale di informazioni in memoria indipendente dal Db e non lo confondo con sysSql che riguarda la comunicazione col db SqlServer! Così quando leggo sysXmlSrl so che mi riferisco alla serializzazione di istanze in modo fedele all'Xml mentre se leggo sysRtmSrl so che la serializzazione è fedele al tipo .NET a discapito dell'Xml.
Questo è il vantaggio più importante che ho riscontrato ma ce ne sono altri. Ecco xKé nel codice mi piace usare gli alias e mi piacciono meno i semplici using.
Tags : Progettazione Software |
___________________________
[1] Strumenti Della Programmazione Object Oriented
[2] Paradigma Di Programmazione Modulare