Pubblicato nella Rubriki Numero 4 - 14 Dic 2006 da LucaMinudel

Questa è una lista di caratteristiche che il disegno di una applicazione può esprimere. La lista non prende in considerazioni scelte architetturali e requisiti non funzionali che ci sono per una specifica applicazione e non considera nemmeno le priorità che ogni singolo team può scegliere per se tra le varie qualità che un buon disegno può esprimere. La lista quindi contiene le caratteristice di base del disegno di una applicazione che hanno una validità generale.

Le caratteristiche sono elencate a partire dagli aspetti più macroscopici che cioè hanno un impatto ampio sull'intera applicazione proseguendo via via con gli aspetti di dettaglio che invece hanno un impatto più localizzato; per questo da quanto ho provato con un approccio graduale conviene cominciare a risolvere eventuali problemi partendo dal primo punto della lista per passare solo in seguito al successivo.

• Sono raggruppati nello stesso Assembly i tipi che solitamente vengono rilasciati e riutilizzati insieme ?
• Azione correttiva: raggruppare in un Assembly i tipi che solitamente vengono evoluti e rilasciati insieme condividendo lo stesso versioning, e che solitamente sono riutilizzati insieme (formando un grappolo di tipi strettamente correlati) e che condividono le medesime impostazioni di sicurezza; assicurarsi che non ci siano dipendenze cicliche tra gli Assembly definiti per una applicazione e in modo di ridurre le dipendenze tra Assembly distinti?'''
• Approfondimenti:
• CriteriPerRaggruppareClassiENamespaceInAssembly
• http://www.ndepend.com/Metrics.aspx/#RelationalCohesion
• http://www.objectmentor.com/resources/articles/granularity.pdf
• Sono raggruppati nello stesso namespace i tipi logicamente correlati e i namespace organizzati (nidificazione tra di loro, contenimento nello stesso Assembly o in Assembly distinti) secondo la loro relazione logica e in modo di ridurre le dipendenze tra namespace distinti?
• Azione correttiva: definire i namespace, muovere le classi nel namespace opportuno, organizzare i namespace in Assembly
• Approfondimenti: StrumentiDellaProgrammazioneObjectOriented#namespace e il PatternGRASP chiamato PatternHighCohesion applicando il concetto di coesione a livello di tipi appartenenti ad un namespace
• Le classi pubbliche hanno un nome che descrive il ruolo e la responsabilità della classe, i membri pubblici un nome che rappresenta la funzione svolta, i parametri dei metodi pubblici un nome significativo che rappresenta il significato del parametro?
• Azione correttiva: rinominare classi, membri e parametri con dei nomi intuitivi e comprensibili a prima vista per un nuovo utilizzatore
• guardando con sospetto i nomi di classi che indicano azioni/verbi invece che oggetti/concetti e quelle che usano il suffissi tipo XxxManager e XxxController
• differenziando i nomi dei metodi pubblici che effettuano un solo calcolo senza modificare lo stato della classe (tipo IsXxx, GetXxx, CheckXxx, ExistsXxx, ContainXxx) dai nomi dei metodi pubblici che modificano lo stato dell'oggetto (SetXxx, AddXxx, etc.)
• Le responsabilità sono ripartite in modo chiaro tra le classi?
• Azione correttiva: spostare i membri di una classe che non assolvono alle responsabilità specifiche della classe individuando la classe più adatta.
• Approfondimenti: il PatternGRASP chiamato PatternHighCohesion applicando il concetto di Cohesion a livello dei membri della classe, quello chiamato PatternInformationExpert e quello chiamato PatternDontTalkToStrangers; il CatalogoDeiPatternDiRefactoring (Moving Features Between Objects).
• Sono state eliminate le classi di soli dati e di sole funzioni residue della programmazione procedurale?
• Azione correttiva: assegnare i dati e le funzioni alle classi a cui compete la relativa responsabilità.
• Approfondimenti: il PatternGRASP chiamato PatternInformationExpert e la CodeSmellDataClass.
• Sono state rimosse le dipendenze circolari tra Assembly e classi e sono state eliminate le dipendenze non necessarie tra classi di assembly diversi e tra classi di namespace diversi?
• Azione correttiva: tracciare il diagramma delle dipendenze e individuare quelle che vanno rimosse.
• Approfondimenti: il PatternGRASP chiamato PatternLowCoupling e i design pattern PatternFacade, PatternMediator, PatternObserver, PatternBridge e PatternVisitor.
• L'ereditarietà è stata utilizzata unicamente nei casi effettivamente necessari?
• Azione correttiva: sostituire l'ereditarietà con il contenimento.
• Approfondimenti: EreditarietàOppureContenimento e il Refactoring chiamato RefactoringReplaceInheritanceWithDelegation.
• La classi e i metodi troppo lunghi sono state spezzati in modo da renderli comprensibili?
• Azione correttiva: scomporre le classi ed i metodi più lunghi.
• Approfondimenti: le CodeSmell chiamate CodeSmellLargeClass, CodeSmellLongMethod, CodeSmellLongParameterList.
• Gli algoritmi più complessi sono stati semplificati e sono comprensibili?
• Azione correttiva: Modificare l'algoritmo semplificandone il flusso, utilizzando nomi parlanti per le variabili, scomponendolo dove possibile e rimuovendo ottimizzazioni non indispenzabili sino a renderlo comprensibile ad un nuovo programmatore che lo legge.
• Approfondimenti: il principio PrincipioKiss, la CodeSmell CodeSmellSwitchStatements e i Refactoring a livello di metodo.

Quando si inizia a lavorare su codice legacy che non si conosce ho notato che conviene iniziare a considerare gli aspetti di granularità pià grossa (assembly, namespace) per poi scendere via via in giù mentre si comprende e si riorganizza il codice.

Quando si scrive nuovo codice o su codice che si conosce ho notato che conviene partire a considerare gli aspetti a granularità più fina (algoritmo, metodo) lasciando emergere via via le scelte di disegno a granularità più grossa.

Lascia qui sotto le tue considerazioni e commenti: [Modifica]