"Hei, Amigo! Vi har endelig kommet til noe virkelig interessant. I dag skal jeg fortelle deg om multippel arv . Multippel arv er virkelig et veldig fascinerende og kraftig verktøy. Og hvis det ikke var for flere problemer, så Java ville støtte multippel arv av klasser. Men det gjør det ikke, så vi må være fornøyd med multippel nedarving av grensesnitt . Noe som også er ganske fantastisk."

Arve flere grensesnitt - 1

Tenk deg at du skriver et dataspill. Og karakterene (objektene dine) må oppføre seg på svært komplekse måter: gå rundt på et kart, samle gjenstander, utføre oppdrag, kommunisere med andre karakterer, drepe noen, redde noen andre. La oss si at du har klart å dele opp alle objektene i 20 kategorier. Dette betyr at hvis du er heldig, vil du kunne klare deg med bare 20 klasser for å definere objektene dine. Men her er fangsten: hvor mange unike former for interaksjon vil disse objektene ha? Hver type objekt kan ha unike interaksjoner med 20 andre typer objekter (vi teller også interaksjoner med objekter av samme type). Med andre ord, du må skrive kode for 20 x 20 = 400 interaksjoner! Og hvis antallet unike objekttyper ikke er 20, men 100, kan antallet interaksjoner være 10 000!

Java university

"Whoa! Nå forstår jeg hvorfor programmering er så vanskelig arbeid."

"Det er enkelt. Takket være mange abstraksjoner. Og med ingen liten takk til flere grensesnitt."

Vi kan ofte forenkle objektinteraksjon hvis roller og/eller evner samhandler i stedet for selve objektene. Og som vi allerede vet, kan evner enkelt legges til en klasse når den implementerer et grensesnitt.

Når du skriver et stort program, gjør utviklere vanligvis dette helt fra starten:

1) Identifiser alle evner/roller.

2) Definer samspillet mellom disse rollene.

3) Deretter tildeler du roller til alle klassene.

"Kanskje et eksempel?"

"Selvfølgelig. La oss se på roller i tegneserien «Tom og Jerry»."

Java-kode Beskrivelse 
interface Moveable
{}
 — Rolle/evne til å bevege seg. 
interface Eatable
{}
 — Rolle/evne til å bli spist. 
interface Eat
{}
 — Rolle/evne til å spise noen. 
class Tom extends Cat implements Moveable, Eatable, Eat
{}
 Tom er en katt som har tre roller:
1) Han kan bevege seg
2) Han kan spise noen
3) Han kan bli spist av noen (en hund)		 
class Jerry extends Mouse implements Moveable, Eatable
{}
 Jerry er en mus som har to roller:
1) Han kan bevege seg
2) Han kan bli spist av noen		 
class Killer extends Dog implements Moveable, Eat
{}
 Killer er en hund med to roller: 1) Han kan bevege seg 2) Han kan spise noen

Når du kun kjenner disse tre rollene (grensesnittene), kan du skrive et program og beskrive den riktige interaksjonen mellom disse rollene. For eksempel vil et objekt jage (via Moveable-grensesnittet) etter «den du kan spise» og løpe fra «den som kan spise deg». Og alt dette uten å vite om spesifikke objekter. Hvis du legger til flere objekter (klasser) til programmet og beholder disse rollene, vil det fortsatt fungere vakkert og kontrollere oppførselen til objektene dine.