Java & OO.

Presentasjon om: "Java & OO."— Utskrift av presentasjonen:

1 Java & OO

2 Om objekter Objekt: Software entitet (ting) Brukes av andre objekter
Eksponerer et view (også interface, type): Meldinger objektet forstår Hva en bruker (klient) kan gjøre med et objekt er avhengig hvilket view klienten har Views kan være implisitt eller eksplisitt

3 Bruk av objekter Et objekt kan aksesseres gjennom ett eller flere views (fargede) Forskjellige klienter kan bruke samme objekt gjennom forskjellig views Objekt Klient Klient

4 Objekter: Hvorfor Mange objekter representer ting som eksisterer i virkeligheten Objekter har Levetid Oppførsel Tilstand (dvs. de kan huske hva som har skjedd med dem)

5 Bruk av objekter Bruk av et objekt Bruk av flere objekter
ViewName var = ....; var.doSomething(); var.doSomethingWith(8); // 8 er en parameter Bruk av flere objekter ViewName var = ...; OtherView other = ...; var.doSomethingWith(other); // var kan bruke other i sin behandling av meldingen ”doSomethingWith”

6 Klasser Objekter med likheter er i samme klasse
Hver objekt tilhører nøyaktig én klasse En klasse kan være spesialisering av en annen klasse (arv – alle Hunder er Dyr)

7 Forhold mellom objekter: Arv
Et objekt kan brukes som sin klasse, eller en superklasse Dersom vi refererer til Hunden ’Max’ som et Dyr: Kan vi bare bruke Max’s egenskap i kraft av et dyr, men Vi kunne også byttet ut bruken av Max med Katten Marie (som også er et Dyr, men ikke en Hund) Vi trenger ikke å bry oss med Max’s ekstra egenskaper

8 Subklasse-superklasse
En spesialisert klasse kalles også en subklasse En generell klasse kalles også en superklasse Hver klasse kan kun ha én superklasse Alle dyr Alle hunder Alle katter Max Marie

9 Interfaces Klasser snakker om hva objekter er
Interfaces snakker om hvilke roller de spiller For eksempel: Max er en Hund, men han er også en Forsikringsfordel ettersom han er en prisbelønnet vakthund Sikkerhetslåsen vår er også en Forsikringsfordel Max og Låsen har ikke mye til felles, men når forsikringspolisen behandles, kan de behandles likt

10 Polymorfi ”Mange former”
Forskjellige objekter kan reagere forskjellig på samme melding Eksempel: Max.beregnForsikringsFordel() -> ser etter om Max har gått på dressurkurs, hvor gammel Max er etc. Lås.beregnForsikringsFordel() -> låstype.forsikringssats Alle metoder som implementerer en melding bør Ha samme formål Ha en felles garanti (postkondisjon) -> Semantisk ekvivalens

11 Aktivitetsobjekter Eksempel: Vi ønsker å spesifisere en bit med kode
Timer.executeAt(myTask, new Date(“2001/09/01 14:00:00”)); Timer.executeEvery(myOtherTask, 600); aCollection.doForEach(myActivity); aWindow.whenClickedDo(myOtherActivity); new Thread(myThirdTask).start(); Vi ønsker å spesifisere en bit med kode I mange språk (C/C++): Funksjonspekere

12 Aktivitetsklasser public interface Runnable { public void run(); }
public interface ActionListener { public void actionPerformed(ActionEvent e); }

13 Implementasjon public class MyTextListener { public void actionPerformed(ActionEvent e) { System.out.println(“The action was performed”); } } field = new JTextField(); field.addActionListener(new MyTextListener()); Vil skrive ut teksten når man trykker Enter i tekstfeltet

14 Blokker, closures Action klasser blir ofte små (som over)
Noen språk støtte derfor et eksplisitt blokk-konspept Kalles ofte closures Eks: (Smalltalk) textField whenActionPerformed: [ |action| ‘Action performed’ printOn: stdout. ]

15 Anonyme klasser Java støtter hverken blokker eller funksjonspekere
Dette er det nærmeste vi kommer: field.addTextListener(new ActionEvent() { public void actionPerformed(ActionEvent e) { System.out.println(“ActionPerformed”); } }); Bedre kjent som anonyme indre klasser

16 Klasser versus objekter
To objekter bør være av forskjellige klasser, dersom de har vesensforskjeller i hvordan de oppfører seg eller i hva slags data de bruker. En klasse kan ofte ha kun ett objekt, men dette

17 Gjenbruk Et ofte brukt argument for objektorientering

18 Noen prinsipper Liskov’s Substitusjonsprinsipp (LSP)
The Open-Closed Principle (OCP)

19 Utviklingsaktiviteter
Analyse Design Implementasjon Testing

20 Analyse Forstå problemet Definere krav for løsning
Utgangspunkt i kravdokument eller intervju av brukere/kunder Definere krav for løsning Testbare krav er de beste

21 Design Tenke ut en løsning på problemet
Modellere løsningen for å oppnå bedre forståelse Nøkkelverktøy: UML

22 Implementasjon Iverksette den design’ede løsninger

23 Testing Kontrollerer at man har:
Utviklet programmet riktig – Design/enhetstesting Utviklet det riktige programmet – Analyse/akseptansetesting

24 Er det så enkelt? NEI Man kan ikke ta høyde for alle tingene man oppdager underveis Praktisk og teoretisk umulig Blir værre jo større systemet er => Gjør litt analyse, litt design, litt implementasjon, litt testing, om og om igjen (Iterativ utvikling)

25 Spesielle klasser Aksjoner
Hendelser (eks. MouseEvent – eller Exception) Assosiasjoner (eks. Abonnement, OrdreLinje, Bestilling, Salg) Tilstand Samlinger Generelt: Er det knyttet varierende oppførsel til noe, kan det være en bra klasse

26 Gode klasser Utgjør en logisk enhet (high cohesion)
Har en veldefinert oppgave (responsibility) Kan forståes i isolasjon (low coupling) Eier all sin data Kan forståes uten å kjenne innholdsdetaljer (abstraction) Bør forståes uten å lese innholdet Er fokusert på logiske oppgaver (intension, responsibility) og ikke fysiske oppgaver eller mekanikk Eksempel:Customer, ikke DataTranslator

27 Hva er et godt design? “Jeg vet det når jeg ser det”
Enklere å beskrive med eksempler

28 Hva er dårlig design? (From Anti-Patterns)
The Blob: One large objekt holding too much responsibility Spaghetti (Finnes også i OO) (From CodeSmells) Duplicated Code Classes more interested in other classes variables than their own Arrow (deeply nested if/else)

29 Hva er gode design? Klasser som kan forståes alene Få if-tester
Klassser som ikke bryr seg så mye om hverandre Klasser som her én veldefinert oppgave

30 Man ser ikke så ofte godt design i virkeligheten