Delegeringsteknikken

Delegering er en teknikk hvor et objekt tilbyr et sett metoder og bruker et internt objekt til å utføre logikken, dvs. delegerer oppgaven til det interne objektet.

Delegering i det virkelige liv handler om at én person kan ta ansvar for å utføre noe for en oppdragsgiver, men overlater til den annen (delegaten) å gjøre selve jobben uten at dette (nødvendigvis) synliggjøres for oppdragsgiveren. Den som delegerer (den delegerende) får evner til å utføre oppgaver, basert på delegatens evner og ens myndighet over denne. Denne rollefordelingen er også nyttig innen objektorientering: et objekt benytter seg av et annet for å utføre en del av en tjeneste.

En typisk bruk av delegering er for å realisere en 1-n-assosiasjon, som er kapslet inn med metoder for å lese antall elementer, hente ut et bestemt element basert på indeks og legge til og fjerne elementer. Ta CD- og Track-klassene og tracks-koblingen som eksempel:

public class CD {

    private List<Track> tracks = new ArrayList<Track>();
    
    public int getTrackCount() {
        return tracks.size();
    }

    public Track getTrack(int index) {
        return tracks.get(index);
    }
    
    public void addTrack(Track track) {
        if (! tracks.contains(track)) {
	        tracks.add(track);
		}
    }

    public void removeTrack(Track track) {
        tracks.remove(track);
    }
}

Klassediagrammet og koden til venstre viser hvordan tracks-assosiasjonen er realisert. Vi ser at den er kapslet inn med en rekke metoder og at realiseringen bruker en intern ArrayList. Alle innkapslingsmetodene kaller bare tilsvarende metoder i ArrayList-objektet, uten noe særlig mer logikk. Vi sier at CD delegerer til ArrayList. Sekvensdiagrammet til høyre illustrerer hvordan CD-objektet bruker ArrayList-objektet.

Selv om vi hadde lagt til litt validering og annen logikk, så hadde alt grovarbeidet i praksis blitt utført av ArrayList-klassen, og uten å delegere og dermed (gjen)bruke logikken i ArrayList-klassen, så ville CD-klassen blitt mye mer kompleks.

Dette er typisk for delegeringsteknikken:

Den delegerende klassen har et internt objekt av delegat-klassen, altså objektet som det delegeres til, som gjør det meste av grovarbeidet.
Den delegerende klassen har metoder med samme eller lignende navn som metoder i delegat-klassens.
Disse metodene delegerer mer eller mindre direkte til metoder i delegat-objektet.

Sekvensdiagrammet illustrerer den generelle teknikken godt, bare bytt ut CD med delegerende og ArrayList med delegat.

I dette tilfellet er det faktum at en bruker delegering ikke på noen måte synlig utenifra, fordi det ArrayList-objektet opprettes internt i klassen og det gis ingen direkte tilgangen til det, siden det jo er kapslet inn. Men i mange tilfeller er litt av poenget at en utenifra kan styre hvilket objekt det delegeres til og dermed påvirke totaloppførselen. Dette illustreres av følgende eksempel.

Vi skal lage en iterator som går gjennom (genererer) annenhvert element i en liste, men istedenfor å knytte den direkte til en List (eller Collection/Iterable), så lar vi den delegere til en annen iterator:

public class EverySecondIterator implements Iterator<Object> {
	
	private Iterator<Object> iteratorDelegate;
    
    public EverySecondIterator(Iterator<Object> iterator) {
        this.iteratorDelegate = iterator;
    }
    
    @Override
    public boolean hasNext() {
        return iteratorDelegate.hasNext();
    }

	@Override
    public Object next() {
        Object o = iteratorDelegate.next();
        if (iteratorDelegate.hasNext()) {
            iteratorDelegate.next();
        }
        return o;
    }
}

Vi ser at hvert kall til hasNext() vil resultere i et kall til hasNext() på delegaten (iteratorDelegate). Hvert kall vil next() vil imidlertid gi først et kall til next() på delgaten og så et kall til hasNext() og evt. et nytt kall til next(). Effekten av det andre kallet til next() er å bruke opp / hoppe over annenhvert element: det første elementet brukes, det andre kastes, det tredje brukes og det fjerde kastes osv. hasNext()-kallet er der for å unngå å utløse unntak ved at vi hopper over et element som ikke finnes.

Et viktig poeng her, ut over bruken av delegering, er at konstruktøren tar inn delegaten, slik at den som bruker EverySecondIterator, kan bestemme hvilken iterator det delegeres til, dvs. hvor elementene egentlig kommer fra. I følgende kode-eksempel kommer elementene fra en vanlig liste:

List<Object> list = new ArrayList<Object>(Arrays.asList(1, 2, 3, 4, 5, 6));
// produces every second element in list
Iterator<Object> it2 = new EverySecondIterator(list.iterator());
// prints 1 3 5
 while (it2.hasNext()) {
	System.out.print(it2.next() + " ");
}

En EverySecondIterator-instans kan delegere til en annen EverySecondIterator, for dermed å hoppe over flere elementer:

List<Object> list = new ArrayList<Object>(Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9));
// produces every fourth element in list
Iterator<Object> it2 =
	new EverySecondIterator(new EverySecondIterator(list.iterator()));
// prints 1 5 9
while (it2.hasNext()) {
	System.out.println(it2.next() + " ");
}

Page tree

Delegeringsteknikken