Continuiamo con lo smell: Duplicated Code Problema: Abbiamo 2 o più metodi che eseguono lo stesso codice anche se con una sequenza logica diversa. Un esempio di logica errata:   Code Snippet     class Employee     {         public int...

Continuiamo con lo smell: Long Method     Problema: Logiche condizionali vengono usate per le richieste di dispaccio e per eseguire azioni. Un esempio di logica errata: Code Snippet             if (ac.Name.Equals("ATTACCO"))                 // ...             else if (ac.Name.Equals("DIFESA")) ...

Continuiamo con lo smell: Primitive Obsession    Problema: Gestire le condizioni dello stato di un oggetto è complicato e complesso. Un esempio di logica errata: while (command != 'e') { Console.WriteLine("\nWhat would you like to do now?"); Console.Write("Move Attack Stop Run Panic CalmDown Exit the game: ==>"); ...

Continuiamo con lo smell: Conditional Complexity   Problema: Collegandoci al post precedente: Conditional Complexity: Replace Conditional Logic with Strategy continuiamo con un’altra possibile soluzione Un esempio di logica errata: // Prima string result = stringBuilder.ToString(); if (shouldDecode) result = MyDecoder.decode(result); return result; // Dopo 1 settimana string result = stringBuilder.ToString(); if (shouldDecode) result = MyDecoder.decode(result); if (removeTabs) result = MyDecoder.withOutTabs(result); return result; // Dopo 2 settimane string result =...

  Continuiamo con lo smell: Conditional Complexity Problema: Esiste un metodo di controllo con una logica condizionale composta da diverse varianti i quali valori si conosceranno solamente a runtime. La stessa logica di controllo viene riprodotta in varie classi affinchè si ottenga il valore desiderato. Un esempio di logica errata: Di seguito un esempio di logica errata, sul quale lavoreremo: public double Capital(){ ...

Continuiamo con lo smell: Indecent Conditional Logic Questo smell l’ho creato io questa mattina. Nel senso che ho trovato del codice che non mi piaceva e ho voluto trovare una soluzione. Problema: Il client crea dei tipi con valori di default se le condizioni sono vere o altrimenti con i valori passati. Motivazione: L’esponenziale presenza di if mi irrita l’epidermide e, nel codice che andremo a vedere, di if non ce ne sono poche. Tentendo questa logica, avremo un proliferare di condizioni inutili lungo tutto il nostro progetto. Un esempio di logica errata: Ecco...

Continuiamo con lo smell: Duplicated Code Problema: Due o più classi, gerarchicamente implementate (ovvero avendo la stessa classe base), contengono lo stesso metodo. Solitamente questo smell nasce dal copia&incolla o perchè non si conoscono le classi sviluppate precedentemente (e questo può essere uno smell causato dal nome usato per le vecchie classi o perchè non abbiamo fatto un pò di Pair Programming). Motivazione: Innanzitutto nella programmazione Object-Oriented, la strada più frequente e più pulita per creare un oggetto è il pattern Factory Method. ...

Continuiamo con lo smell: Indecent Exposure   Problema: Il client istanzia direttamente un oggetto che risiede in una libreria.   Motivazione: Durante la realizzazione di una libreria, si potrebbe cadere nella tentazione di creare delle classi che istanziano oggetti di cui il client necessita. Un esempio di logica errata: Ciò significa dare al client la responsabilità di conoscere tutti gli oggetti presenti nella nostra libreria. class Program { ...

Continuiamo con lo smell: Solution Sprawl    Problema: La creazione di un oggetto avviene recuperando dati e codice in giro per il nostro progetto.   Motivazione: Quando la creazione di un oggetto avviene tramite il passaggio di più classi si ha uno smell di tipo creation sprawl (Code Smells), questo tipo di smell nasce da un design dell’applicazione nato troppo presto (questo capita quando siamo convinti che l’analisi del sistema possa essere completa e corretta al 100%).   Un esempio di logica errata: Il client ha bisogno di un oggetto Button che deve essere disegnato a seconda del sistema operativo. L’oggetto Button per essere disegnato deve chiamare il metodo...

Continuando la serie di post sui smells, inizio ad introdurre i possibili smell e le relative possibili soluzioni. Il primo che affronteremo riguarda una classe con 5 costruttori (anche se personalmente già 2 costruttori sono troppi):   public class Loan { public Loan(string commitment, int riskRating, int maturity) public Loan(string commitment, int riskRating, int maturity, DateTime expiry) public Loan(string commitment, string outstanding, int riskRating, int maturity, DateTime expiry) public Loan(int capitalStrategy, string commitment, int riskRating, int maturity, DateTime expiry) public Loan(int capitalStrategy, string commitment, string outstanding, int riskRating, int...

Far Refactoring, o migliorare il design del codice esistente, richiedere innanzitutto capire qual’è il codice da migliorare. Quindi avere un elenco di ciò che è smell nel vostro codice è fondamentale: Duplicato Non chiaro Complicato Questi criteri possono certamente aiutarci a scoprire il codice da migliorare. Questa lista, per alcuni, risulta troppo generica. Per questo motivo, Martin Fowler e Kent Beck, hanno creato una libro per identificare i problemi di design (fate pure riferimento all’indirizzo: http://foozle.berkeley.edu/projects/streek/agile/bad-smells-in-code.html#DuplicatedCode. L’autore ha fatto un riassunto del libro di MF e KB). In questo post elencheremo solamente di 12 dei...

Martin Fowler: "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior" Chi tra voi non ha mai lavorato su un vecchio codice, di un vecchio progetto?!?! Beh beati voi... a me, purtroppo, è capitato spesso. In questo contesto il refactoring si fa strada, per rimuovere duplicati di codice, semplificarne la complessità logica e per chiarire il codice esistente. Possiamo fare del refactoring su grossi pezzi di codice o solamente sul nome di una variabile, importante è che il tutto migliori la comprensione del codice. Ricordiamoci che è buona norma effettuare...

  Motivazione al refactoring: Sviluppare una classe con più costruttori creerà qualche disagio allo sviluppatore che dovrà decidere a quale costruttore affidarsi per istanziarla; questo comportà un certo tempo di studioe dei parametri dei costruttori e/o magari del codice stesso dei costruttori. Più costruttori abbiamo nella nostra classe più sarà complicato capirne il comportamento. Per di più, spesso, molti dei costruttori che creeremo non verranno mai utilizzati appunto per via della complessità nel doverne studiare il comportamento. Soluzione: Il Creation Method può aiutare a rendere il tutto più semplice. Il Creation Method è un metodo statico o non statico utilizzato per creare una nuova...