Præsentation er lastning. Vent venligst

Præsentation er lastning. Vent venligst

STREAM processen – Programmering i praksis

Lignende præsentationer


Præsentationer af emnet: "STREAM processen – Programmering i praksis"— Præsentationens transcript:

1 STREAM processen – Programmering i praksis

2 Det store hvordan… Hvordan? Programmer som virker… Værktøj Sprog
Specifikation Intellekt Programmer som virker… Hvordan? RHS – HHX IT A

3 Programmerings-processen
Vi har ikke fokuseret så meget på selve processen for programmering Vi har lært om Et værktøj (”her er en hammer”) Sprog (”dette kan du med en hammer”) Eksempler (”her er nogle pæne huse”) …men er det nok til, at vi kan bygge et hus efter specifikationen? RHS – HHX IT A

4 Programmerings-processen
Hvilke aktiviteter er involveret i at skrive et korrekt program? I den ideelle verden: Forstå – læs specifikationen indtil du forstår den fuldstændigt Tænk – tænk grundigt over, hvordan problemet skal løses Kod – skriv selve programmet! En simpel, lineær proces…som desværre ikke rigtig virker i praksis  RHS – HHX IT A

5 Den ideelle verden Forstå Tænk Kod RHS – HHX IT A

6 Den virkelige verden Forstå Tænk Kod Test RHS – HHX IT A

7 Hvordan kommer vi i gang?
Givet at vi har opnået en rimelig forståelse af problemet, hvordan kommer vi så videre? Den traditionelle metode kaldes trinvis forfining RHS – HHX IT A

8 Trinvis forfining public class MyMainClass {
public void solveProblem() // Indsæt kode her... } RHS – HHX IT A

9 Trinvis forfining Herfra brydes problemet ned i mindre og mindre bidder Kode udvikler sig fra at være abstrakt til at blive konkret Stadig en for naiv strategi Antager at vi ved ”alt” om problemet Stadig en lineær proces En mere realistisk proces er trinvis forbedring RHS – HHX IT A

10 Trinvis forbedring Trinvis forbedring rummer to aktiviteter mere end trinvis forfining Udvidelse: vi udvider kodens funktionalitet til at dække mere af specifikationen Restrukturering: vi ændrer kodens struktur, uden at ændre kodens funktionalitet RHS – HHX IT A

11 Aktivitets-diagram Forfining Målet Vi er her… Udvidelse
Restrukturering RHS – HHX IT A

12 Trinvis forfining Forfining Målet Udvidelse
Nu forstår vi alt om problemet, så vi begynder at kode! Restrukturering RHS – HHX IT A

13 Trinvis forbedring Forfining Målet Udvidelse Restrukturering
RHS – HHX IT A

14 Vær åben for ændringer…
Er Trinvis forbedring helt kaotisk!? Nej, men kan virke forvirrende  Der er ingen given rækkefølge af aktiviteterne, de kan forekomme til enhver tid i processen Bemærk dog, at det stadig er separate aktiviteter Lad os se på, hvordan vi kan udføre hver af de indgående aktiviteter RHS – HHX IT A

15 Udvidelse I den virkelige verden er en krav-specifikation stor, mangelfuld og modstridende… Giver det i så fald mening at prøve at løse alle problemer på én gang…? Vi vælger i stedet en begrænset del af funktionaliteten, og prøver at få den del til at virke. RHS – HHX IT A

16 Udvidelse Når den udvalgte del af funktionaliteten er klar, kan vi inkludere endnu en del Før vi gør det, vil vi muligvis udføre noget forfining og/eller restrukturering Måske vil selve specifikationen også have ændret sig… RHS – HHX IT A

17 Forfining Når vi udfører denne aktivitet, prøver vi at få den valgte del af funktionaliteten til at virke Aktiviteten involverer kun programmering Pas på med at være alt for ”smart”; forfining er rigeligt kompliceret i sig selv… Den såkaldte STREAM proces er en rimeligt simpel model for at udføre forfining RHS – HHX IT A

18 STREAM processen Stubbe Test Repræsentation Evaluering Attributter
Metoder RHS – HHX IT A

19 Stubbe Hvad er en ”stub” – en metode som endnu ikke rummer noget kode
Vi antager, at vi er i gang med at udvikle en ”vel-forstået” klasse Vel-forstået: Klassens forventede opførsel er vel forstået Vi burde være i stand til at specificere klassens interface (public metoder) RHS – HHX IT A

20 Stubbe public class BankAccount { public void deposit() {}
public void withdraw() {} public double getBalance() return 0.0; } RHS – HHX IT A

21 Stubbe For alle de vel-forståede klasser kan vi lave klasser med stub-metoder Et sådant program vil oversætte fint – men kan naturligvis ingenting På engelsk kaldes et sådant program walking skeleton RHS – HHX IT A

22 Test Vi har antaget, at de klasser vi arbejder med alle er vel-forståede Altså burde vi være i stand til at skrive test-tilfælde for alle klasserne Det giver os et veldefineret mål – når program-met klarer alle vores test-tilfælde, er vi færdige med aktiviteten Hvis vores test-tilfælde er gode nok… RHS – HHX IT A

23 Repræsentation Når vi arbejder med stub-metoder, skal vi ikke tænke over, hvordan data skal repræsenteres Data-repræsentation er ikke en del af en klasses interface, men vi skal stadig vælge en repræsentation De forskellige muligheder for hvordan data repræsenteres skal evalueres RHS – HHX IT A

24 Evaluering Evaluering: Hvor vanskeligt vil det være at kode metoderne i klassens interface, givet en bestemt repræsentation? Vil i nogen grad være en subjektiv vurdering Evaluér hver metode for hver mulig data repræsentation REM: Repræsentations-Evaluerings-Matrix RHS – HHX IT A

25 Evaluation REM double String deposit Nem Medium withdraw getBalance
Triviel RHS – HHX IT A

26 Attributter Når vi har bestemt os for en repræsentation, skal vi benytte den D.v.s.: Definér instans-variable Initialisere dem i klassernes konstruktører Vi kan muligvis få brug for flere instans-variable, når vi færdiggør metoderne Kan anvende samme princip for disse RHS – HHX IT A

27 Attributter public class BankAccount { double balance;
public BankAccount() balance = 0.0; } public void deposit() {} public void withdraw() {} public double getBalance() return 0.0; RHS – HHX IT A

28 Metoder Nu mangler vi bare at fylde kode ind i de tomme metoder…
…men det er jo også det svære! Når vi gør dette, bruger vi faktisk nogle af trinnene i STREAM igen Der findes diverse ”råd og regler” til at hjælpe os med at kode metoderne RHS – HHX IT A

29 Metoder Det vigtigste princip er at holde kompleksiteten under kontrol, ved at bryde problemerne ned i mindre – men mere overskuelige – problemer Skub problemerne foran dig! Gør koden i metoderne simpel, ved at opfinde nye metoder undervejs Kod de nye metoder som stubbe, og gør dem færdige senere Mañana princippet (eller ønskefeen) RHS – HHX IT A

30 Mañana princippet public void convertFromInchesToCm() {
double inches = getInchesFromUser(); double cm = calculateCmFromInches(inches); presentCmToUser(cm); } private double getInchesFromUser() return 0.0; private double calculateCmFromInches(double inches) private void presentCmToUser(double cm) {} RHS – HHX IT A

31 Mañana princippet Hvornår kan vi bruge mañana princippet
Specialtilfælde: Flyt koden for special-tilfælde til separate metoder Indlejrede løkker: Hvis du har en indlejret løkke, flyt den inderste løkke til en separat metode Svært problem: Hvis du har brug for et svar på et svært problem, så flyt koden for problemet til en separat metode Tung funktionalitet: Hvis en metode bliver meget lang eller kompleks, så del den op i separate metoder RHS – HHX IT A

32 Metoder Mañana princippet er ikke en regel, men et princip – udvis rettidig omhu… Grænsen for, hvornår man synes det skal anvendes, vil være individuel Tommelfinger-regel: Metoder bør ikke fylde så meget, at hele metoden ikke kan ses på et enkelt skærmbillede Husk at det stadig er vores test-tilfælde, der afgør om vi er færdige eller ej RHS – HHX IT A

33 Hold oversætteren glad
Lavpraktisk råd, men godt  Oversætteren prøver at finde alle fejl i koden på én gang Fejlbeskeder fra oversætteren kan være ganske kryptiske Prøv kun at rette de fejl, der giver reel mening Heldigvis er oversættelse hurtigt, så gør det ofte RHS – HHX IT A

34 Hold oversætteren glad
Oversæt dit program ofte! Hold dit program fri for syntaks-fejl til enhver tid Ret fejl med det samme! Når oversætteren kun rapporterer få fejl, er det lettere at overskue at rette fejlene Fejlen(e) må være i den kode, du lige har tastet ind RHS – HHX IT A

35 Eksempel: Date klassen
Vi skal udarbejde en Date klasse, med følgende specifikationer: Date klassen repræsenterer en dato, givet ved år, måned og dag (månedsnummer og dagsnummer) Når et Date objekt skabes, bliver det initialiseret med år, måned og dag (vi antager, at den initielle dato altid er en valid dato) Det skal være muligt at ændre datoen i objektet til den næste valide dato Det skal være muligt at få datoen ud af objektet, i form af en tekst-streng RHS – HHX IT A

36 Date klassen – Stubbe public class Date {
public Date(int year, int month, int day) } public void advanceToNextDate() public String toString() return null; RHS – HHX IT A

37 Date klassen – Test Vi går ikke i detaljer med testen her, men der er ganske mange test-tilfælde Simpelt tilfælde Henover månedsskift Henover årsskift Skudår …og så videre Pointen er; vi kan udarbejde alle test-tilfælde uden at kende implementationen RHS – HHX IT A

38 Date klassen– Repræsentation
Hvordan kan vi repræsentere en dato? Tekst-streng – vi skal jo kunne returnere datoen i form af en tekst-streng Flere talværdier – en for dag, en for måned og en for årstal En talværdi – antal dage siden 1/1, år 1 Vi bruger REM-metoden til at evaluere disse alternativer RHS – HHX IT A

39 Date klassen– Evaluering
REM Tekst Flere tal Et tal Date Nemt Triviel Svært advance… Medium toString RHS – HHX IT A

40 Date klassen – Attributter
public class Date { private int year; private int month; private int day; public Date(int year, int month, int day) this.year = year; this.month = month; this.day = day; } public void advanceToNextDate() public String toString() return year + ”-” + month + ”-” day; RHS – HHX IT A

41 Date klassen – metoder Nu skal vi ”bare” kode metoden advanceToNextDate() Første forsøg: public void advanceToNextDate() { date = date + 1; } RHS – HHX IT A

42 Date klassen – metoder Noget naivt, men virker faktisk i 97% af alle tilfælde  Der er et special-tilfælde, vi skal håndtere Næste forsøg: public void advanceToNextDate() { date = date +1; handleDayOverflow(); } RHS – HHX IT A

43 Date klassen – metoder Nu virker advanceToNextDate(), under antagelse af at handleDayOverflow()virker! Dette er netop mañana princippet! Nu skal vi lave handleDayOverflow() private void handleDayOverflow() { if (day > 30) day = 1; month = month + 1; } RHS – HHX IT A

44 Date klassen – metoder Dette virker, bortset fra to tilfælde
Måneder der ikke har 30 dage Henover et årsskifte Igen opfinder vi nogle metoder, der skal håndtere disse special-tilfælde: daysInMonth() handleMonthOverflow() RHS – HHX IT A

45 Date klassen – metoder private void handleDayOverflow() {
if (day > daysInMonth()) day = 1; month = month +1; handleMonthOverflow() } private int daysInMonth() return 30; private void handleMonthOverflow() {} RHS – HHX IT A

46 Date klassen – metoder Og så videre, og så videre…
I den endelige implementation vil alle tilfælde naturligvis blive håndteret korrekt Hold kompleksiteten under kontrol – løs eet problem af gangen Lad være med at tænke for meget over, om koden har den rette struktur – det ser vi på under restrukturering RHS – HHX IT A

47 Restrukturering I forfiningsaktiviteten er fokus på at øge funktionaliteten Tænk ikke for meget over kodens struktur Under restrukturering kan vi, restrukturere koden, men bevare funktionaliteten Meget nemt at glemme dette i virkeligheden… RHS – HHX IT A

48 Restrukturering Hvordan ved man, hvad der skal restruktureres?
Kræver erfaring at finde ud af Man skal udvikle en evne til at opdage ”ildelugtende kode” Hvad er det…? RHS – HHX IT A

49 Hmm, dårlig navngivning…?
Ildelugtende kode… Hmm, dårlig navngivning…? private void hDO() { if (d > dIM()) d = 1; m++; hMO() } private int dIM() return stdDiM; RHS – HHX IT A

50 Restrukturering Simpelt – men relevant - eksempel
Andre mulige ”oprydnings-aktiviteter”: Inkonsistent navngivning Erstat ”magic numbers” med konstanter Kode-layout Fjern ubrugte parametre til metoder Husk, ingen ændringer i funktionalitet! RHS – HHX IT A

51 Ildelugtende kode… public void printWorkerInfo(Employee worker) {
System.out.println(”Worker information”); System.out.println(” ”); System.out.println(worker.GetName()); System.out.println(worker.GetAddress()); } public void printManagerInfo(Employee manager) System.out.println(”Manager information”); System.out.println(manager.GetName()); System.out.println(manager.GetAddress()); RHS – HHX IT A

52 Velduftende kode… public void printWorkerInfo(Employee worker) {
printEmployeeInfo(worker, ”Worker information”); } public void printManagerInfo(Employee manager) printEmployeeInfo(manager, ”Manager information”); public void printEmployeeInfo(Employee person, String header) System.out.println(header); System.out.println(” ”); System.out.println(person.GetName()); System.out.println(person.GetAddress()); RHS – HHX IT A

53 Restrukturering Restrukturering kan ske på flere niveauer
Internt i metoder Mellem metoder, internt i klasser Mellem klasser Restrukturering kaldes mere generelt for refactoring NetBeans kan hjælpe med refactoring Bedste værktøj er erfaring  RHS – HHX IT A


Download ppt "STREAM processen – Programmering i praksis"

Lignende præsentationer


Annoncer fra Google