Ved programmering av klasser for dataorienterte objektstrukturer så tar en ofte utgangspunkt i såkalte datamodeller, i form av klassediagrammer, som viser hvordan klasser (ofte kalt entiteter) er koblet sammen med assosiasjoner (ofte kalt relasjoner). En datamodell beskriver altså hvilke regler og begrensninger som gjelder for hvordan objekter kan kobles sammen under kjøring, men sier ikke hvilke som faktisk blir koblet sammen. F.eks. kan en datamodell beskrive at personer (altså instanser av klassen Person) kan kobles sammen for å representere ekteskap, men diagrammet sier ikke noe om hvilke instanser som faktisk er koblet sammen.
Dersom en datamodell har nødvendige detaljer, som vi kommer nærmere inn på, så kan koden for klassene skrives mer eller mindre automatisk, og det finnes verktøy, f.eks. Eclipse-rammeverket EMF, som kan generere koden for deg. For å bruke slike verktøy riktig, så er det imidlertid viktig å kjenne grunnteknikkene, dvs. hvordan ulike typer assosiasjoner mellom klasser kan kodes.
La oss starte med et ekteskaps-koblingen mellom Person-objekter. Denne er modellert under til venstre med et klassediagram og eksemplifisert ved et objektdiagram, som viser at Hallvard er gift med Marit.
Person-klassen og ekteskap-assosiasjonen | public class Person {
private String name;
private Person ekteskap;
public Person(String name) {
this.name = name;
}
public Person getEkteskap() {
return ekteskap;
}
public void setEkteskap(Person ekteskap) {
this.ekteskap = ekteskap;
}
}
| hallvard er koblet til marit med en ekteskap-kobling
| // lage eksempel-objekter
Person hallvard = new Person("Hallvard");
Person marit = new Person("Marit");
// opprette ekteskap-koblingen fra hallvard til marit
hallvard.setEkteskap(marit);
|
Klassediagrammet sier at Person-klassen har en assosiasjon kalt ekteskap til(bake) til seg selv, dvs. at et Person-objekter kan være koblet til et Person-objekt med en ekteskap-kobling. Objektdiagrammet viser et tenkt tilfelle der hallvard er koblet til marit. Det er lett å tenke seg at dette kan kodes i Java som en Person-klasse med et felt av typen Person kalt ekteskap (ved siden av name-feltet, selvsagt) og innkapslingsmetodene getEkteskap() og setEkteskap(), som vist over. Objekter tilsvarende diagrammet til høyre kan så lages med konstruktøren og setEkteskap-metoden.
I denne koden er det en del antagelser som er gjort, f.eks. at et person bare kan inngå ekteskap med én annen person (altså monogami). Det er også en opplagt mangel, fordi koden ikke sikrer at ekteskapskoblingen er gjensidig, dvs. at marit automatisk får en kobling tilbake til hallvard. Generelt er både (feil)antagelser og mangler uheldig, fordi de kan føre til ugyldige og inkonsistente objektstrukturer. Før vi koder klassene er det derfor viktig å legge til en del "detaljer" i klassediagrammet, slik at "nyanser" som dette fremgår av diagrammet.
Roller og multiplisitet
En rolle er en assosiasjon sett fra perspektivet til en ene enden, altså fra den ene til den andre. Siden en assosiasjon har to ender, så har den også to roller. Roller er nødvendig fordi logikken knyttet til assosiasjonen som helhet nødvendigvis må fordeles på metoder i hver klasse, og disse metodene må ha perspektivet til klassen de er i. Ta institutt-emne-assosiasjonen som sier hvilke emner et institutt gir, som eksempel. Sett fra institutt-enden (sett mot emne-enden) er det naturlig å kalle den emner, mens det fra emne-enden (sett mot institutt-enden) er naturlig å kalle den ansvarlig-institutt. Disse navnene kan gi opphav til metoder som addEmne i Institutt-klassen og setAnsvarligInstitutt i Emne-klassen. En tommelfinger-regel er nettopp at rolle-navnet er greit, hvis navnet på innkapslingsmetodene virker greit.
Rolle-navnet brukes altså for å navngi metoder som implementerer logikken for assosiasjonen, altså hvordan koblinger opprettes og fjernes. Men akkurat hvilke metoder en har og hva disse gjør og dermed heter, avgjøres av det som kalles rollens multiplisitet (ofte kalt kardinalitet). Multiplisiteten til en rolle angir hvor mange koblinger som kan (eller må) gå fra et objekt i rolle-retningen. Multiplisiteten til emne-rollen sier altså hvor mange emner et institutt kan ha ansvaret for (mer enn ett), og multiplisiteten til ansvarlig-insitutt-rollen sier hvor mange institutter som kan ha ansvaret for et emne (ett og bare ett). Multiplisitet angis ofte av en minimum- og en maksimum-verdi, altså et intervallet. Ofte er minimum-verdien 0 og da kan den utelates. Rolle-navnet og multiplisiteten angis sammen i enden av assosiasjonen, men ofte på hver sin side av streken: