Lab 5: TDD Calisthenics

Transcript

1 Dept. of Computer Science Lab 5: TDD Calisthenics Matteo Camilli Progettazione del Software a.a. 2014/15 1

2 Obbiettivi del laboratorio Capire quando il codice che scrivete necessita refactoring Come sistemarlo? Is it testable? Is it readable? Why does my code sucks? Is it reusable? Is it maintainable? 2

3 Obbiettivi del laboratorio 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. Sono linee guida.. non regole! 4

5 OC #1 Usare un solo livello di indentazione per metodo. public void format(){ 0 Più leggibilità for (int row=0; row<rows; row++) { 1 for (int column=0; column<columns; column++) { 2 grid[row,column].format(); Benefici 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(); 5

6 OC #2 Non utilizzare la parola chiave else execution paths if(form.isvalid()) if(!form.isvalid()) { return entity new = new Message( Invalid Post(form); fields ); Benefici repository = this.getrepository( Post ); if(!repository.exists(entity)) entity { = new Post(form); repository repository.save(entity); = this.getrepository( Post ); message = new Message( create_ok ); if(repository.exists(entity)) { else{ return message new = Message( Post new Message( Post Title Title already already exists ); exists ); else{ repository.save(entity); return message new = Message( create_ok ); new Message( Invalid fields ); Più leggibilità (meno ramificazioni) Evita duplicazione del codice Testing più semplice Bad OK return message; 6

7 OC #3 Non usare parametri di tipo primitivo (es. int, double) e di tipo String. Creare invece delle Classi che incapsulano i tipi primitivi e rappresentano il significato di questi tipi per il programma. Più leggibilità public class UIComponent { public class UIComponent { public void repaint(animate public void repaint(boolean Benefici animate){ animate){ public class Animate { component.repaint(false); private boolean animate; Più manutenibilità Operazione non chiara! public Animate(boolean animate){ this.animate = animate; component.repaint(new Animate(false)); Bad OK 7

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

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

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

11 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. 11

12 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; 12

13 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à! 13

14 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... Benefici collection.setelements(objects); Bad Aiuta ad associare responsabilità alle classi giuste. collection.filter(...); collection.append(...); collection.map(...) OK 14

15 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. 15

16 Esercizio - FizzBuzz Scrivere un programma Java usando approccio TDD. Il programma, dato un numero intero n, restituisce una stringa con l elenco dei numeri da 1 a n con le seguenti regole: Feature1: se un numero è multiplo di 3 viene restituito fizz al posto del numero. Feature2: se un numero è multiplo di 5 viene restituito buzz al posto del numero. Feature3: se un numero è multiplo di 3 e di 5 viene restituito fizzbuzz al posto del numero. L esercizio è guidato da una serie di requisiti che vi forniremo. Ad ogni nuovo requisito: 1. Tradurre il requisito in un test. 2. Implementare la funzionalità che fa passare il test. 3. Refactoring indicando nel commento le regole utilizzate. 16

17 Come Lavorare Test Driven Development (TDD) (Red, Green, Refactoring) Commit ad ogni step Usare git flow git flow feature start <name> git flow feature finish <name> git flow release start <release> git flow release finish <release> 17

18 Per la consegna se siete in una situazione stabile (nessuna feature ancora aperta) git flow release start consegna git flow release finish consegna git push se siete in mezzo all implementazione di una feature prima di quanto sopra: git flow feature publish <nome feature ancora aperta> 18

19 Esercizio - FizzBuzz (parte 2) Implementazione con conditional statement nasconde diversi problemi... if( numero è multiplo di 3 ){ decora output if( numero è multiplo di 5 ){ decora output if( numero è multiplo di 7 ){ decora output if( numero contiene 3 ){ decora output if( numero contiene 5 ){ decora output if( numero contiene 5 ){ decora output... Lack of modularity Mischiamo logica applicativa Poor readability e infrastruttura del Non programma. conciso e codice ripetuto. Software rigidness Per aggiungere una nuova funzionalità devo modificare codice esistente. 19

20 Chain of Responsibility Pattern da usare quando vogliamo dare a più di un oggetto la possibilità di gestire una richiesta. Attraverso questo pattern creiamo una catena di oggetti per esaminare una richiesta. Ogni oggetto della catena gestisce la richiesta oppure la inoltra al prossimo oggetto della catena. Benefici Disaccoppiamento sender e receiver della richiesta. Semplifica gli oggetti poiché non hanno visione dell intera catena. Possiamo aggiungere o rimuovere responsabilità dinamicamente a runtime cambiando gli oggetti della catena. 20