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); } } | Vi ser at tracks-assosiasjonen 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. 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 mulighet til å delegere og dermed (gjen)bruke logikken i ArrayList-klassen, så ville CD-klassen blitt mye mer kompleks. Dette er typisk for delegeringsteknikken:
|
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.