Da er det jo ikke rart du ikke forstår. Player er et interface, ser du. Alle metodene er abstrakte - tomme og ubrukelige. Klasser som arver fra et interface må implementere alle metodene. Det eneste Player selv inneholder, er regler for hvordan subklasser ser ut og oppfører seg.
Player er en del av Bukkit, et API som er designet for å representere forskjellige implementeringer av Minecraft serveren (først og fremst, men ikke kun CraftBukkit). Bukkit har også regler for hvordan implementeringer skal se ut og oppføre seg. For eksempel bestemmer Bukkit at implementeringen må sørge for at Bukkit.getPlayer(UUID) returnerer et objekt som følger reglene til Player.
I de fleste tilfeller representerer Bukkit CraftBukkit. Ved å fordøye
kildekoden til CraftBukkit kan vi skimte at Bukkit.getPlayer(UUID) som regel er en instans av CraftPlayer, som implementerer Player. Men siden CraftPlayer ikke er en del av APIet har man ikke grunnlag for å vite dette, og det regnes som veldig dårlig idé å bruke funksjoner fra CraftBukkit uten at det foregår gjennom APIet.
En annen ting å tenke på er at man aldri kaller konstruktøren til Player - Player er abstrakt og har ingen konstruktør. Man kaller APIet, som gir deg en instans av en ukjent klasse som implementerer Player. Derfor må man bruke en form for proxy for å omdirigere de interessante metodene fra Player-instansen. Oftest vil man bruke
dekoratørmønsteret, men i tilfelle interfacet er stort, noe man trygt kan si at Player er, blir det forferdelig rotete å bruke dekoratørmønsteret.
Javas refleksjon går ut på å bruke eller manipulere klasser på en måte som bestemmes ved runtime. Refleksjon er ikke mulig i programmeringsspråk som C og C++.
Klokka er mye nå...
Dokumentasjon på PlayerKildekoden til PlayerKildekoden til CraftPlayer
Vis innlegg
