Videregående programmering i Java

Dag 4 - objektorienteret design

Fremlæggelse af analyse/status for projekter

Objektorienteret design

Datastrukturer: Afbildinger (hashtabeller og træer)

Evt.: Datastrukturers interne virkemåde og kørselstider

Evt.: Arv og Delegering

Specificere funktionalitet i et interface

Ansvarsområder, kobling og indkapsling (programmere i pakker)

Læsning: VP 1.2-1.6, VP 15.3, VP 15.6-15.7, evt VP 15.1-15.2

plus analysedel i kapitel 22 i http://javabog.dk (udleveret)

Dette materiale er under Åben Dokumentlicens, se http://www.sslug.dk/linuxbog/licens.html

Vector-klassens interne virkemåde

Hvordan fungerer Vector-klassen internt?

variabler

metoder

isEmpty()

firstElement()

elementAt()

addElement()

removeElementAt()

Kørselstider og Store-O-notationen

Store-O

tiden en operation tager som funktion af antal elementer n

O(1) - konstant i tid

Eksempel: Slå et element op i et array

O(log(n)) - logaritmisk

O(n) - proportionalt

Eksempel: Gennemløbe alle element i et array

O(n2) - kvadratisk (hmm...)

O(en) - eksponentielt (uha!)

En Map (da.: afbilding) beskriver nøgle-værdi-par
HashMap ord = new HashMap();
ord.put("estas", "(det) er");
ord.put("bona", "god");
ord.put("granda", "stor");
ord.put("longa", "lang");
ord.put("hundo", "hund");
esperantoOrd = "granda";
// slå esperantoordet op og få det danske ord
danskOrd = (String) ord.get( esperantoOrd );

Afbildninger
(nøgleindekserede lister)

Hashtabeller

hashCode() beregner hashkoden af et objekt

en 'næsten' unik nøgle, beregnet ud fra objektets data

et andet objekt med samme data har samme hashkode

andre objekter har en anden hashkode (i 99% af tilfældene)

alle de almindelige klasser har en god hashCode()-metode

hashkoden/nøgleværdien anvendes som indeks i et (stort) array, hvor elementet gemmes.

Hvis man vil slå et bestemt objekt (nøgle) op, beregnes dens hashværdi og der slås op på det pågældende indeks

Træer

I et binært søgetræ har hver indgang en reference til

en indgang med lavere værdi og

en indgang med højere værdi

Indgangene er altid sorteret efter værdi

n = 2antal lag-1 ⇒ søgning og indsættelse er O(log(n))

Kørselstider og Store-O-notationen

Opgave: Find kørselstid for LinkedList, ArrayList, TreeSet, HashSet, for indsættelse, sletning, opslag, søgning

O(1) - konstant i tid

Eksempel: Slå et element op i et array

O(log(n)) - logaritmisk

O(n) - proportionalt

Eksempel: Gennemløbe alle element i et array

O(n2) - kvadratisk (hmm...)

O(en) - eksponentielt (uha!)

Evt.: Holdninger til arv (VP 15.1)

To holdninger til arv

Den kodenære, "amerikanske"

Arv bruges til at genbruge variabler og metoder. Hvis to klasser har fælles variabler eller metoder, bør man lave en fælles superklasse, der tager vare på de ting, der er fælles.

Formål: spare kode

'nedefra-og-op'-strategi

Den analytiske, "skandinaviske"

Arv repræsenterer en er-en-relation, og nedarving bør ske mellem klasser, når de begreber, som de står for, har en 'er-en'-relation til hinanden.

Formål: analyse, overskuelighed, klarhed

'oppefra-og-ned'-strategi

Evt.: Holdninger til arv (VP 15.1)

Evt.: Delegering i stedet for arv
(VP 15.2)

(droppes - behandles måske senere i kurset)

Hønsespil

Ebbe +

Regnskabssystem m flere brugerflader

Kim J +

Yatzy for flere spillere

Ratha +

Regelbaseret produktkonfigurator

Michael C ??

Styring af astronomisk kiggert

prototype t afg.proj) - Mikael M +

Hønsespil

Michael K (+)

Netværksovervågningsværktøj

Nødstrømsanlæg, tavler - Peter (+)

Forudsige farten af en sejlbåd

(empirisk/modelforsøg) - Kim H (+)

Visuel GIS-konfiguratioseditor (XML)

Christian (+-)

Netværkssniffer

Thomas og Haris (!)

Grafisk overvågning af driftsdata

Carl +

Rapportkonvertering/håndtering?

Anders og Atle !

Visuel formel-editor (a la Word)

Preben +

Regnskabssystem

Mikala +

Fremlæggelse af analyse/
status for projekter

Modularitet

Programmer er ofte for store og for komplekse til at blive designet og implementeret som ét system.

De bør derfor deles op i håndtérbare moduler

"Del og hersk"

Principper for modulerne:

Hvert modul bør have et klart ansvarsområde

Modulerne bør have lav kobling indbyrdes

Kohæsion og kobling

Kohæsion

Hvor relaterede funktionerne, der varetages inden for et modul, er

Metoderne i en klasse bør gøre relaterede ting

Ergo: Høj kohæsion er godt

Kobling

Handler om graden af afhængighed, der er mellem modulerne

Modulerne bør stort set være uafhængige og kun løst forbundet

Ergo: Lav kobling er godt

Specificere funktionalitet i interface
(VP 15.3)

Adskil grænsefladen
fra implementeringen

Klarhed

Lav kombling

F.eks. mulighed for andre implementeringer senere

Hvordan

I Java: interface

I C++: rent abstrakt klasse

multipel arv

Indkapsling

Veldesignede moduler indkapsler (eng.: encapsulate) informationerne og skjuler deres repræsentation for andre moduler ("klienter"), der bruger modulet

"Need to know"-princip

Hvis et modul ikke har behov for at vide det, får det det ikke at vide

Klienter skal vide hvad et modul gør, ikke hvordan det gør det

Princip:

Adskil et moduls (et objekts) implementation fra grænsefladen (interfacet) til modulet.

Indkapsling med pakker

Et modul, der består af flere klasser, kan lægges i sin egen pakke

metoder/variabler, der er interne for modulet erklæres med pakke-synlighed (ingenting)

modulets klasser indkapsles derved, så at klasserne kan tilgå hinandens metoder/variabler, mens de ikke er synlige udefra

Ansvarsområder

Ansvarsområder for et objekt/modul kan være:

At oprette nye objekter eller udføre en beregning

At foretage en handling i andre objekter

At kontrollere og koordinere aktiviteter i andre objekter

At kende private data

At kende relaterede objekter

At kende ting, som objektet kan beregne

Høj kohæsion (sammenhæng - eng.: high cohesion)

at et objekt har ét overskueligt og let forståeligt ansvarsområde (eller eventuelt flere områder tæt relaterede til hinanden)

Designfase

Hvordan skal programmet fungere

Redskaber til objektorienteret design

Ord til klasser

Kollaborationsdiagrammer

Klassediagrammer

Vi bruger nu 10 minutter til hvert punkt!

Fremlæggelse næste gang!

Ord til klasser

Tommelfingerregler:

Navneord (substantiver) i ental bliver ofte til klasser

Klassenavne skal altid være i ental

Udsagnsord (verber) bliver ofte til metoder

Kollaborationsdiagrammer

Husk ansvarsområder

Forskelligt antal => forskellige klasser

Tegn (har)relationer på

Klassediagrammer

To-vejs-redigering med et UML-udviklingsværktøj

TogetherJ

JDeveloper

PoseidonUML

Videregående programmering i Java

Præsentatoner fra kurset

2004-08-30T12:23:21