Forelæsning 7/10 2003: Java, nedarvning, Java Platform, konventioner og Collections API m.v.

Læsestof: Kap. 6 i lærebogen + referencer til kap. 1-4.

Bogens kapitel 6 er noget vandfaldsagtig i sin introduktion til "Collections API" og vi tager her en mere struktureret tilgang ved at tage udgangspunkt i opbygningen af sproget Java og dets omgivelser kaldet "platform".

Dette dokument er kun beregnet til at fungere i sammenhæng med en forelæsning og skal altså ikke tages som stykke online lærebogslitteratur.

Dokumentet indeholder links til SUNs online dokumentation, som var gyldige oktober 2003, men der garanteres ikke for deres aktualitet, ej heller om de vil være gyldige på et senere tidspunkt.

Primær indgang er: http://java.sun.com/j2se/1.4.2/docs/api/index.html

Formål

• Data-abstraktion: Der beskrives interfaces og klasser for div. datastrukturer; forstå nu udelukkende gennem metoder - implementation senere i kurset.
• Hvordan generisk kode kan opnås gennem Javas objektorienterede faciliteter.
• Hvordan Javas medfølgende samling biblioteker er organiseret.
• Kritisk vurdering af Java som programmeringssprog.

Kort om Java

• Objektorienteret sprog med nedarvning
• Popularitet opnået pga. internettets opblomstring
• Forcen ligger ikke i sprogets design (....) men i
  • Faciliteter til internetprogrammering.
  • Platformsuafhængigt
  • Biblioteker ("packages" her omtalt som "pakker") til stort set alt
  • Mere eller mindre lykkedes at gøre disse generiske
• Vægt på dataabstraktion: Faktisk repræsentation (og dermed metode-indmad) ikke tilgængelig eller interessant.

Programmering i Java

• Specifisere, designe, eksperimentere
• Vælge detailimplementation snarere end at konstruere fra bunden hver gang
• Problemer
  • At navigere rundt i alle de mange pakker, klasser og interfaces
  • At hitte rede på Javas nedarvningsmekanismer
  • At der skal skrives utroligt mange linier uden ret meget information for at nedarve og tilpasse
  • At manglende typeparameterisering (m.v.) medfører brug af overgenerel klasse "Object" og meget dynamisk typecheck.

• Arrays er eksempel på en konstruktion parameteriseret med typer, "a = new MinType []".
• "Dynamisk" = på kørselstidspunkt (run time), modsat "Statisk" = på oversættelsestidspunkt (compile time)

Byggesten i Java

• Simple typer
  • byte 8-bit heltal
  • short 16-bit heltal
  • int 32-bit heltal
  • long 64-bit heltal
  • float 32-bit flydende tal
  • double 64-bit flydende tal
  • char Unicode tegn
  • boolean
• At bygge nye typer
  • arrays
  • klasse- og interfacedefinitioner
    - m. "extends" og "implements"

Konventioner

• Enhver klasse er (implicit) underklasse af Object
• Generisk klasser/metoder ofte beskrevet i termer af Object
  - ofte som underklasser af Object og/eller interface
• Simple typer er ikke ikke klasser, derfor behov for "wrapper classes", dvs. objekt med simpel værdi indeni, f.eks. Integer

Eksempel på "hjælpeklasse"

• Bemærk overloading for "simple-type []" og generisk for Object.
• Klassebegreb bruges her til at gruppere statiske metoder; ingen interessante objekter.

Eksempel på generisk datastruktur

• Ligesom et array, men kan vokse.
• Bemærk indhold er af type Object.
• Man kan ikke bede om en "ArrayList of CPRrecord"!
  - konsekvens: Programmør må overholde egne konventioner, risiko for runtime fejl.

Vigtige generelle klasser og interfaces

• Object
• Comparable
  Bemærk uheldig assymmetri mellem de to argumenter til "compareTo"; følgende ikke godt:
  class A implements Comparable; {... int CompareTo(A o);{...} ...}
  (metoden har anden "signature" end den i interface, så "overloading" og ikke specialisering),
• Comparator
  Eksempel på at skabe "function objects", dvs. indpakke en metode i objekt der kan sendes med som parameter.
  F.eks. Sortere efter dato, afsender, "subject" i postprogram m. samme sorteringsmetode
  (se bogens 4.7.3 + fig. 4.34 for "anonymous classes" som forenkler notation).

Generelle datastrukturer for samlinger af objekter

Om metoden Iterator iterator()

Fordel ved adskillelse af (konkret) Iterator fra (konkret) Collection (modsat startIterator, hasNext og Next som metoder på Collection):

• Iterator er selvstændigt objekt.
• Man kan have flere aktive iteratorer på samme Collection objekt.
• En iterator kan sendes med som parameter til generisk metode

Faktum: Ikke altid nemt at finde Iterator-klasse eller for given klasse.
F.eks. prøv at finde iteratorer til ArrayList og til HashSet ved at lede her

Specialiserede versioner af Collection

• Interface List extends Collection: samlinger med rækkefølge (index)
  • LinkedList, ArrayList, ...
• Interface Set - uden gengangere
  • interface sortedSet extends Set
  • Class HashSet implements Set
    - kommer vi til senere på kurset
    - stort set O(1) indsætte og finde
  • Class TreeSet implements SortedSet
    -stor set O(log(n)) indsætte og finde med sortering opretholdt

Noget om

Generelle værktøjskasse for Collection

Bemærk mismask af generelt og specifikt, og ting til det teknisk set urelaterede interface Map!!

Historien om igen for afbildninger

Intuitivt og matematisk: Blot specialiseret "Set" af par (Nøgle, Værdi) med egenskab at til en nøgle hører max. en Værdi.

Men i java.util realiseret som separat interface klasser (hvorfor mon?)

interface Map
- bemærk ved metoden "values" i interface Map såvel som class HashMap returnerer et Collection-objekt, men der står ikke hvilken "slags" Collection!! (Collection er specifiseret som interface)

Andre interessante datastrukturer diskuteret i bogen:

Konklusion

• Java leveres med langt det meste af, hvad man får brug for af generelle datastrukturerer og algoritmer.
• Der skal meget gode grunde til at skrive f.eks. sin egen hashtabel
  (overvej hvilke!)
• Et hav af pakker til alle mulige formål tilgængelige
• En ikke indlysende opdeling i interfaces, klasser og underklasser,
  men online dokumentation gennemført med hyperlinks er en stor hjælp!

Grundlæggende egenskaber i Java som giver problemer og besvær

• Manglende typeparameterisering medfører intens brug af Object klassen,
  • Potentielle runtime fejl
  • Dynamisk typecheck som ku' ha' været gjort statisk
• Brug af Object klassen for generiske ting medfører
  
  • assymmetri mellem simple typer og klasser
  • -> "wrapper klasser" og gentaget kode (f.eks. i Arrays)
  • ditto problem med arrays:
    • Oprettes med "new" som var de objekter men er ikke undertype(r) af "Object".
• Hvis metoder var "first class citizens" kunne man spare mange sære klasser.
• Javaprogrammer typisk fyld med 1000vis af linjer uden ret meget indhold når klasser og deres metoder specialiseres.

Tænk hvis man ku' skrive

Sidst rettet 6. oktober 2003