Java & OO

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

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

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)

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”

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)

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

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

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

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

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

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

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

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

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

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

Gjenbruk Et ofte brukt argument for objektorientering

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

Utviklingsaktiviteter Analyse Design Implementasjon Testing

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

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

Implementasjon Iverksette den design’ede løsninger

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

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)

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

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

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

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)

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

Man ser ikke så ofte godt design i virkeligheten