Lab 3: TDD Calisthenics

Transcript

1 Università degli Studi di Milano Dept. of Computer Science Lab 3: TDD Calisthenics Matteo Camilli Progettazione del Software a.a. 2012/13 1

2 Obbiettivi del laboratorio Capire quando il codice che scrivete fa schifo : Manutenibile? Leggibile? Riusabile? Testabile? Come sistemarlo? 2

3 Object Calisthenics Cal-is-then-ic - noun Calisthenics are a form of dynamic exercise consisting of a variety of simple, often rhythmical, movements, generally using minimal equipment or apparatus. 3

4 Object Calisthenics Cal-is-then-ic - noun Calisthenics are a form of dynamic exercise consisting of a variety of simple, often rhythmical, movements, generally using minimal equipment or apparatus. Nel nostro contesto: Una varietà di semplici e ritmici esercizi per ottenere un migliore OO e una migliore qualità del codice. 3

5 Object Calisthenics Cal-is-then-ic - noun Calisthenics are a form of dynamic exercise consisting of a variety of simple, often rhythmical, movements, generally using minimal equipment or apparatus. Nel nostro contesto: Una varietà di semplici e ritmici esercizi per ottenere un migliore OO e una migliore qualità del codice. Sono linee guida.. non regole! 3

6 OC #1 Usare un solo livello di indentazione per metodo. public void format() for (int row=0; row<rows; row++) for (int column=0; column<columns; column++) grid[row,column].format(); VS public void format() for (int row=0; row<rows; row++) formatrow(row); public void formatrow() for (int col=0; col<columns; col++) grid[row,col].format(); 4

7 OC #1 Usare un solo livello di indentazione per metodo. public void format() Benefici for (int row=0; row<rows; row++) for (int column=0; column<columns; column++) grid[row,column].format(); Più leggibilità Metodi svolgono un unica funzione. Maggiore riusabilità del codice. VS public void format() for (int row=0; row<rows; row++) formatrow(row); public void formatrow() for (int col=0; col<columns; col++) grid[row,col].format(); 4

8 OC #2 Non utilizzare la parola chiave else if(form.isvalid()) entity = new Post(form); repository = this.getrepository( Post ); if(!repository.exists(entity)) repository.save(entity); message = new Message( create_ok ); else message = new Message( Post Title already exists ); else message = new Message( Invalid fields ); Bad return message; 5

9 OC #2 Non utilizzare la parola chiave else Flusso di esecuzione if(form.isvalid()) entity = new Post(form); repository = this.getrepository( Post ); if(!repository.exists(entity)) repository.save(entity); message = new Message( create_ok ); else message = new Message( Post Title already exists ); else message = new Message( Invalid fields ); Bad return message; 5

10 OC #2 Non utilizzare la parola chiave else if(form.isvalid()) entity = new Post(form); repository = this.getrepository( Post ); if(!repository.exists(entity)) repository.save(entity); message = new Message( create_ok ); else message = new Message( Post Title already exists ); else message = new Message( Invalid fields ); Bad return message; 5

11 OC #2 Non utilizzare la parola chiave else if(!form.isvalid()) return new Message( Invalid fields ); OK entity = new Post(form); repository = this.getrepository( Post ); if(repository.exists(entity)) return new Message( Post Title already exists ); repository.save(entity); return new Message( create_ok ); 5

12 OC #2 Non utilizzare la parola chiave else if(!form.isvalid()) return new Message( Invalid fields ); Benefici OK entity = new Post(form); repository = this.getrepository( Post ); Più leggibilità (singolo path di esecuzione) Evita duplicazione del codice if(repository.exists(entity)) return new Message( Post Title already exists ); Testing più semplice repository.save(entity); return new Message( create_ok ); 5

13 OC #3 Non usare parametri di tipo primitivo (es. int, double) e di tipo String. Creare invece degli oggetti che rappresentano cosa sono i parametri. public class UIComponent public void repaint(boolean animate) component.repaint(false); Bad Operazione non chiara! 6

14 OC #3 Non usare parametri di tipo primitivo (es. int, double) e di tipo String. Creare invece degli oggetti che rappresentano cosa sono i parametri. public class UIComponent public void repaint(animate animate) OK public class Animate private boolean animate; public Animate(boolean animate) this.animate = animate; component.repaint(new Animate(false)); 6

15 OC #3 Non usare parametri di tipo primitivo (es. int, double) e di tipo String. Creare invece degli oggetti che rappresentano cosa sono i parametri. Più leggibilità Più manutenibilità public class UIComponent Benefici public void repaint(animate animate) public class Animate private boolean animate; OK public Animate(boolean animate) this.animate = animate; component.repaint(new Animate(false)); 6

16 OC #4 Usare un singolo punto per linea. public void update() context.currentsession.update(); Bad??? public void update() Session s = context.currentsession; s.update(); Bad public void update() context.update(); public class Context public void update() currentsession.update(); OK 7

17 OC #4 Usare un singolo punto per linea. public void update() public void update() context.currentsession.update(); Session s = context.currentsession; s.update(); Benefici??? Più leggibilità Più semplicità di debugging Responsabilità alle classi giuste Bad public void update() context.update(); public class Context Bad public void update() currentsession.update(); OK 7

18 OC #5 Non abbreviare i nomi.? if (sx >= sy) if (sx > strsysmatimgw) ny = strsysmatimgw * sy / sx; nx = strsysmatimgw; if (ny > strsysmatimgh)?? Bad 8

19 OC #5 Non abbreviare i nomi.? I Nomi dei metodi sono troppo lunghi.. if (sx >= sy) if (sx > strsysmatimgw) Bad ny = strsysmatimgw * sy / sx; nx = strsysmatimgw; public void processresponseheadersanddefineoutput()... if (ny > strsysmatimgh) Troppe responsabilità??? 8

20 OC #5 public Page getpage()... public Page downloadpage()... public Page fetchpage() get from where? public void startprocess()... public void forkprocess()... public void createprocess() tr.process(); table row? tablerow.process(); translatorservice.process();... 9

21 OC #5 public Page getpage()... public Page downloadpage()... public Page fetchpage() get from where? public void startprocess()... Più leggibilità Rivela problemi sottostanti Benefici public void forkprocess()... public void createprocess() tr.process(); table row? tablerow.process(); translatorservice.process();... 9

22 OC #6 Non più di 50 righe di codice per classe. Non più di 10 file per package. 10

23 OC #6 Non più di 50 righe di codice per classe. Non più di 10 file per package. Benefici Aiuta a mantenere ogni classe con una singola responsabilità. Oggetti più semplici da utilizzare. 10

24 OC #7 Ogni classe deve avere un massimo di due attributi. public class Person() String first; String middle; String last; public class Person() Names givennames; Surname family; public class Surname() String family; public class Names() List<String> names; 11

25 OC #7 Ogni classe deve avere un massimo di due attributi. public class Person() String first; String middle; String last; Benefici public class Person() Names givennames; Surname family; public class Surname() String family; Aiuta a trovare implementazioni più generiche. Limita responsabilità di una classe. public class Names() List<String> names; 11

26 OC #8 Ogni classe avente una collection come attributo, non deve avere nessun altro attributo. 12

27 OC #8 Ogni classe avente una collection come attributo, non deve avere nessun altro attributo. Benefici Limita le responsabilità della classe: manipolare la collezione è già una responsabilità! 12

28 OC #9 Non usare metodi setter e getter. Dire agli oggetti cosa fare in base al loro stato invece che chiedere qual è il loro stato attuale e agire di conseguenza. Object[] objects = collection.getelements(); // modifica elementi della lista... collection.setelements(objects); Bad collection.filter(...); collection.append(...); collection.map(...) OK 13

29 OC #9 Non usare metodi setter e getter. Dire agli oggetti cosa fare in base al loro stato invece che chiedere qual è il loro stato attuale e agire di conseguenza. Object[] objects = collection.getelements(); // modifica elementi della lista... collection.setelements(objects); Benefici Bad Aiuta ad associare responsabilità alle classi giuste. collection.filter(...); collection.append(...); collection.map(...) OK 13

30 Ricapitolando OC #1: Un solo livello di indentazione. OC #2: Non usare la keyword else. OC #3: Wrappare i tipi primitivi. OC #4: Un solo. per linea. OC #5: Non abbreviare. OC #6: Mantenere le classi piccole. OC #7: Limitare il numero di attributi (2). OC #8: firstclass collection. OC #9: Non usare metodi setter e getter. 14

31 Come Lavorare Test Driven Development (TDD) (Red, Green, Refactoring) Refactoring = seguire linee guida #1,..., #9 Tramite GIT dovete far vedere che avete usato questo approccio: Red - commit Green - commit Refactoring - commit Tracciare solo i file sorgenti del progetto! 15

32 Come usare GIT per l esercizio Creare un solo repository remoto per gruppo su bitbucket. Creare repo locale: $ git init Linkare repo remota: $ git remote add origin [url] Lavorare solo sul branch master Svolgere l esercizio a coppie su due pc. Ad ogni ciclo (Red, Green, Refactoring) si cambia pc e driver. Repository remoto 2. git push 3. git pull 1. git commit 4. pronto a lavorare 16