Avansert bruk av Eclipse - Eclipsekurs fra Mesan

Transkript

1 Avansert bruk av Eclipse - Eclipsekurs fra Mesan Refactoring i fellesskap Utgangspunktet Om refactoring i Eclipse Gjennomføring Kildekoden Kjør! Myk intro - Rename Oops - sjekk kommentarer Siden vi er inne på det - Change Method Signature Endring av klassenavn Hvileskjær Alt i ett - Introduce Parameter Object Ekte innkapsling - Encapsulate Field Uforanderlig - Inline Skjerpings - Extract Interface Langsomt, skyndsomt - Extract Class Frikobling - Introduce Parameter, Use Supertype Where Possible, Introduce Factory Restopplag Eksemplarisk - Extract Local Variable Videre forfremmelse - Convert Local Variable to Field Halvparten av dobbelt - Inline Lastenes sum er - Extract Constant Generalisme i praksis - Generalize Declared Type Extract Method Videre? Utgangspunktet Support International har hatt inne en hospitant fra Faulty Software som har laget en bakgrunnsjobb for å følge opp purring på saker. Den funker i og for seg fint, men når vi nå skal lage den nye jobben for utdatering av foreldede saker over samme lest, oppdager vi jo fort at eksisterende kode ikke helt kvalifiserer som clean... Se BatchResult.java og tro på det du hører...

2 Ved siden av den grusomme målklassen finner du

3 PurreJobb dette er "klienten" som bruker klassen. Den simulerer en kjøring med et antall produsenter og konsumenter som kommuniserer via en kø. Vi skal ikke bruke mye tid inne i denne det aller meste av endringer i denne bør skje automatisk som følge av refactorings. PurreJobbSystemTest en tung test som kjører hele jobben (plussminus 5 sekunder), og sjekker at totalresultatet blir som forventet. Ved siden av å få hakket renere kode, har vi noen absolutte mål for forbedringen av gørra. Vi ønsker å skille jobbkontrolldelen fra telling/rapportering. Vi ønsker å kunne styre rapportering og output friere ikke være låst til et hardkodet format til en tekstfil med magisk navn. Og ikke minst ønsker vi å skille ut det som er spesifikt for akkurat denne jobben (og det er nesten bare sakstelleren) fra det som er generelt. I tillegg er det hardkodet at det skal være en primærjobb med 2 understeg ( public static final int ANTALL_STEG= 2+1; ) vi vil gjerne kunne dele opp i vesentlig flere steg enn det. Om refactoring i Eclipse Vi skal jobbe oss gjennom noen av valgene på menyen Refactoring i Eclipse. Den menyen er fast du får en mer konteksttilpasset (duh) utgave ved å høyreklikke og se på refactoring på kontekstmenyen lett tilgjengelig med *Alt+Shift+T, den viser generelt bare valg som passer til det du har merket (figuren viser resultatet av å merke navnet på en klasse). Gjennomføring Etter hvert steg i gjennomgangen skal vi kjøre gjennom testen(e) for å sjekke at alt fortsatt virker. Det er jo tanken bak "refactoring" å endre "utseende" uten å endre oppførsel... Ta gjerne en kikk på JavaDoc, formatering etc etter hver refactoring, det har en tendens til å krølle seg litt, særlig når man gjør flere steg og koden er ikke-kompilerbar deler av tiden. Alle referanser under gjelder klassen som (i hvert fall foreløpig) heter BatchResult, så fremt annet ikke er sagt dog vil vi etter hvert gjøre denne uinteressant. Kildekoden For å komme fort i gang ligger utgangspunktet for oppgaven som ZIP-fil her: refactoring-utgangspunkt.zip Løsningsforslag finnes her: V0_1.zip Kjør! Vi skal ta de første stegene mot en ny og bedre verden... Myk intro Rename I kildekodemappen src/main/java ligger pakken no.way. Dette var kanskje ikke noe slående pakkenavn. Vi skal flytte oss under no.support (troll i ord?) og dermed omdøpe pakken til no.support.batch.purring.

4 1. Merk pakken i Project Explorer, velg Rename fra menyen Refactoring. 2. Eller trykk ( F2 eller) Alt+Shift+R etter å ha merket pakken man trenger jo egentlig ikke å rote i menyer for alt... Helt magisk skal nå package være riktig i Javafilene. Men vi får en kompileringsfeil i kildekodemappen src/test/java der testen er plassert. Gjør den samme tilpasningen på pakkenavnet og kompileringsfeilen skal være rettet Det er mer enn klasser som kan omdøpes. I klassen BatchResult ønsker vi å endre to metoder. Begge metodene er en del av implementasjon av interfacet ResultCounter. 1. Først endrer vi metoden addok som har et litt misvisende navn den var kanskje tenkt å telle antall OK, men teller i praksis antall forekomster behandlet. Så da bør jo metodenavnet avspeile virkelighet vi endrer navnet til inctotal. 2. Gå til ResultCounter og se at metodenavnet er endret også her. 3. Når vi først er i interfacet så kan vi gjøre tilsvarende endring for metoden getok som vi endrer til gettotal. 4. Gå tilbake til BatchResult og se at endringen også er kommet med her. Dobbeltklikk på metodenavnet, trykk Alt+Shift+R, skriv inn 'inctotal'. OK, og ferdig med den. Det kan hende (avhenger av oppsett) du ikke får opp en dialogboks, men at navnet blir merket, og får en ramme rundt seg. Du kan skrive inn det nye navnet direkte inne i rammen, og trykke Enter når du er ferdig, eller du kan trykke nedtrekkspilen og be om å få dialogboksen (du trenger ofte ikke den til hverdags). Gjør ditto for getok. Vitsen med å bruke en refactoring i stedet for bare å skrive inn nytt navn, er selvfølgelig at vi da også endrer navnet i kallende klasser. For å gjøre dette (over)tydelig, kan vi også omdøpe en variabel i klassen BatchCounter fra counter til total.

5 Dobbeltklikk på variabelnavnet, trykk Alt+Shift+R, skriv inn 'total'. OK, og ferdig Oops sjekk kommentarer Ta en kikk på metodekommentaren for inctotal etter at vi byttet navn. Naturlig nok fikser ikke refactoring på prosa vi må skrive om Tell opp antall OK på egenhånd (nå). Og det gjelder generelt kikk på kommentarer før/etter refactoring, de kommer fort i utakt. Siden vi er inne på det Change Method Signature Kikk enda en gang på inctotal. Den tar to nokså anonyme int som parameter gjett hvor mange som kommer til å lure på hvilken som er stegnummer og hvilken som er antall (eller enda skumlere gjette feil). En kjapp analyse (dobbeltklikk på metodenavnet, trykk Ctrl+Shift+G sjekk referansene som dukker opp i søkevinduet) viser at alle som kaller på denne nå har 1 som antall. Så kanskje er det litt YAGNI å kunne angi antall la oss gå ut fra at den alltid kalles med 1 og heller utsette problemet til en gang noen får behov for bulkoppdatering (kanskje vi rekker å se på det etterpå). Så vi vil ta ta bort parameter nummer 2, antall, fra metoden. Go!

6 1. Dobbeltklikk på metodenavnet, trykk Alt+Shift+C (eller velg Refactor>Change Method Signature). NB: Hvis du akkurat har brukt Ctrl+Shift+G, kan det være Eclipse tror du vil jobbe med markert treff i søkeresultatet i stedet for i editoren dobbeltsjekk at du prøver å endre riktig "ting". Dette gjelder alle refactorings, og er lett å bomme på Svar ja på spørsmålet om at det er greit å gjennomføre operasjonen på denne metoden. Den informerer om at metoden er en implementasjon av interfacet ResultCounter. 3. Marker parameter nr. 2, og trykk Remove. 4. Du vil få en stygg advarsel, men det er greit, vi skal fikse på resultatet det er ikke alltid refactoring er 100% automatisk Vi får kompileringsfeil på addandget(pantall) endre dette til incrementandget(), så blir det bra. Endring av klassenavn Vi har en klasse med et misvisende navn. Dette henger igjen fra en tidligere refaktoreringsjobb som ikke ble ferdigstilt. Omdøp klassen OpptellingOgStyringOgRapporteringForStatusJobb til PurreJobbResultat. Heretter vil vi jobbe mest i no.support.batch.batchresult, ta det som default, så fremt annet ikke er nevnt. Hvileskjær Vi har jobbet hardt nok en stund la oss ta et par enkle... Alt i ett Introduce Parameter Object Let deg frem til report-metoden i BatchResult. Den har 6 strenger som parametere, og trenger åpenbart litt hjelp. Det er rimelig å tro at de 6 strengene tilsvarer hhv venstre, senter og høyre oppe og nede, men detaljene sparer vi til senere. I første omgang lager vi bare en klasse DocumentHeaderFooter som kan innkapsle disse den skal foreløpig ikke ha gettere og settere, bare 6 public String (så kan vi trene på get/set i neste avsnitt).

7 1. 2. Dobbeltklikk på metodenavnet, velg Refactor>Introduce Parameter Object. Angi DocumentHeaderFooter som navn på en toppnivåklasse, fjern krysset på gettere og settere. Ekte innkapsling Encapsulate Field Vi angrer selvfølgelig umiddelbart på at vi ikke lagde gettere og settere i forrige punkt det var jo et helt kunstig påfunn. Gå inn i den nye klassen DocumentHeaderFooter, og gjør om de 6 strengene til private felter med gettere og settere.

8 For hvert av feltene merk feltet og velg Refactor>Encapsulate Field. Forskjellen på å bruke Encapsulate Field og Source>Generate Getters and Setters er at sistnevnte generelt ikke fikser på eksisterende tilganger (men til gjengjeld kan den ta mange av gangen). Uforanderlig Inline Men egentlig vil vi jo gjerne ha et immutable verdiobjekt som konstrueres ferdig i constructoren. Så ved nærmere ettertanke kan du inline alle setterne (så fremt du ikke parprogrammerer med en villmann, er disse nemlig bare i bruk i constructoren). For hver av setxxx-metodene, merk navnet og trykk Alt+Shift+I ( Refactor>Inline). Skjerpings Extract Interface Nå har vi tatt det for rolig for lenge... Videre med forretningsmålene. Nå vil vi trekke ut et interface for jobbstyringen det er typisk de trådorienterte metodene threadsup(), threadsdown(), getthreadcount(), stepdone() vi ønsker å skille ut i et interface ThreadControl.

9 1. 2. Plasser markøren i BatchResult og velg Refactor>Extract Interface Marker de 4 nevnte metodene, pass på at det er krysset av for å benytte Interfacet der mulig. 3. Rydd i etc Langsomt, skyndsomt Extract Class Da har vi grensesnittet, men vi ønsker jo å få ut funksjonaliteten også. Flytt over threadstarted og threadcounter i en egen klasse BatchControl. Denne klassen skal implementere ThreadControl. Denne metoden er ikke spesielt vakker. Ville nok gjort litt mer manuelt hvis ikke poenget var å prøve ut refactorings...

10 Klipp ut de 4 metodene som utgjør ThreadControl i BatchResult ut på et trygt sted f.eks. Notepad Bli stående i BatchResult, og velg Refactor>Extract Class Marker de to feltene threadstarted og threadcounter, og be om ikke å få gettere/settere, angi navnet BatchControl for klassen, og batchcontrol for variabelen (nederst) Men den implementasjonen ble kanskje ikke så vakker. Flytt opprettelsen av BatchControl (dvs = new BatchControl() ) fra deklarasjonen til constructoren, og send med step som parameter (bruk QuickFix for å få den på plass). Gjør feltene i BatchControl om til private final, og flytt over opprettelsen av de enkelte variablene til constructoren. Du bør da ende med en constructor som ser slik ut: BatchControl.BatchControl() public BatchControl( final int step) { this.threadcounter= new AtomicInteger[step]; this.threadstarted= new boolean[step]; for ( int i=0; i< step; i++) { this.threadcounter[i]= new AtomicInteger(); } } Legg til implements ThreadControl, og lim inn metodene slik de tidligere lå i BatchResult. Gå til BatchResult, og endre typen på variabelen batchcontrol til ThreadControl. Marker variabelen batchcontrol, og velg Source>Generate Delegate Methods, rydd gjerne i resultatet.

11 Nytt designmål nådd vi har fristilt trådstyringen Frikobling Introduce Parameter, Use Supertype Where Possible, Introduce Factory Det er alt for mye new i denne koden. Marker hver av new BatchControl, new BatchLogger og new BatchCounter i constructoren i BatchResult, og bruk Introduce Parameter på dem. Pass på å merke hele teksten, f.eks for BatchCounter så merk new BatchCounter(step). Dersom du får kompileringsfeil i constructoren i PurreJobbResultat, så klarer du sikkert å fikse på dem også. Av en eller en annen grunn insisterer Eclipse på å bruke typen til objektet (f.eks. BatchControl) i stedet for typen til variabelen som skal inneholde den (f.eks. ThreadControl). Dette fikser vi ved å gå inn i hver av klassene BatchControl, BatchCounter og BatchLogger, og velge Refactor>Use Supertype Where Possible. Merk de respektive interfacene, og så hvordan constructoren langsom får en penere argumentliste. Så oppretter vi en ny klasse ResultFactory i en ny pakke no.support.batch.factory, hvoretter vi markerer constructoren i PurreJobbResultat og kjører Refactor>Introduce Factory. Kall metoden createresult (vi skal fikse litt på den), og legg den i no.support.batch.factory.resultfactory, men ikke be om privat constructor. Pynt gjerne litt på resultatet, men først og fremst gjør vi om til følgende metode denne er ikke ment å leve public static <T extends BatchResult> T createresult( final Class<? extends T> clazz, final boolean debug) { if ( clazz.isassignablefrom(purrejobbresultat.class)) { return (T) new PurreJobbResultat(debug); } return null; } Restopplag Vi brenner nå etter å gå løs på report-metoden, men det får vente litt vi har et pensum å leve opp til. Eksemplarisk Extract Local Variable er den første på listen. Den kan man jo bruke i et kjør mens man skriver kode, men vi må straks lete litt for å finne et eksempel.

12 Vi kan begynne med bunnen av BatchResult.report() der finner vi den enkle kodelinjen save(new File(("statusfix." + new SimpleDateFormat("yyMMdd-HHmmss").format(new Date()) + ".log"))); her bør det være mulig å trekke ut 2 variable i trekk: begynn med å lage en String av strenguttrykket fra "statusfix" til ".log". Deretter kan vi lage en File av det som gjenstår. Det virker kanskje overflødig, men det koster ingenting runtime, en som debugger vil kanskje takke deg, og syntaksen blir tydeligere. 1. Merk koden fra første fnutt i "statusfix" til siste fnutt i ".log" (Eclipse er ganskje kjip på riktig merking), og trykk Alt+Shift+L ( Refactor>Extract Local Variable). Kall strengen filename. 2. Merk new File(fileName, og trekk ut denne også. Videre forfremmelse Convert Local Variable to Field Det er en uskikk å hardkode filnavn og særlig til ufortsigbare navn som "statusfix log". Så vi ønsker å forfremme filnavnvariabelen fra forrige avsnitt til et felt logfilename i klassen, med get/set-metoder, så får heller den rare verdien få lov til å være default. Fix, please. 1. Merk den nye variabelen filename, og velg Refactor>Convert Local Variable to Field, og be om verdisetting allerede i deklarasjonen. Endre navnet samtidig. 2. Merk det nye feltet, og velg Source>Generate Getters and Setters for å la den bli en konfigurerbar public property. Halvparten av dobbelt Inline Refactoringen Inline kan brukes både på metoder og felt, og kan tidvis være grei for f.eks. å kvitte seg med variable som bare brukes én gang (når innholdet er like beskrivende som variabelnavnet+typen). Vi har så vidt brukt den over, men kan trene litt til på BatchResult.TOM_STRENG, som bare peker videre på EMPTY_STRING. Hvis vi inliner TOM_STRENG, benyttes EMPTY_STRING over alt. Merk TOM_STRENG, og velg Alt+Shift+I ( Refactor>Inline). Lastenes sum er Extract Constant Gå til metoden BatchResult.writeData. Der benyttes \n og \t som konstanter. Vi har i første omgang lyst til å gjøre disse til konstanter hhv LINE_SEP og FIELD_SEP. Skulle det bli god tid, kan du kanskje gjøre mer med disse (kikk i DocumentTable...), men i første rekke trekker vi ut disse som symbolske navn på hhv "ny linje" og "ny kolonne/felt".

13 Merk '\t', velg Refactor>Extract Constant, kall den FIELD_SEP, gjør den public, og kryss av for "Replace all" (men ikke "Qualify"). Gjenta det samme for '\n'. Generalisme i praksis Generalize Declared Type I toppen av BatchLogger finner du, om du har fulgt oppskriftene og ikke vært for flink, deklarasjonen private final LinkedList<String> messages= new LinkedList<String>(). Det er dårlig praksis å benytte mer konkrete typer i deklarasjoner enn du trenger, og collections av ymse slag er et typisk eksempel. Vi ønsker å gjøre om deklarasjonen (på venstre side av likhetstegnet) til en mest mulig generisk type (nei, jeg mener ikke Object...). Merk variabelen, velg Refactor>Generalize Declared Type. Eclipse foreslår noen muligheter, men fokuserer på List<String> gå for den! Extract Method Gå til metoden debug og marker koden som vist på skjermbildet under. Trykk Ctrl + Shift + M og gi den nye metoden et passende navn. Metoden skal være privat.

14 Videre? Per nå ser det omtrent ut som følger dersom du har fulgt opp alle oppfordringene: