Gränssnitt finns för att stödja specifikt beteende

"Hej, Amigo! Idag skulle jag vilja berätta för dig varför gränssnitt finns. Du hör ofta att en viss klass, objekt eller entitet stöder ett visst gränssnitt. Vad innebär det att stödja ett gränssnitt ? "

I en vidare mening är vilket gränssnitt som helst en mekanism för att något ska kunna interagera med något annat. Till exempel är en TV-fjärrkontroll ett fjärrgränssnitt. En hund förstår och utför kommandon, vilket innebär att hunden stöder ett röst-(kontroll)gränssnitt. För att sammanfatta det hela kan vi säga att ett gränssnitt är ett standardiserat sätt för två saker att interagera, där båda parter känner till standarden. När en person säger åt en hund att "sitta" är hans eller hennes kommando en del av ett «hundröststyrningsgränssnitt», och om hunden lyder kommandot, då säger vi att hunden stödjer gränssnittet.

Så är det i programmering. Metoder är åtgärder som utförs på ett objekt, på dess data. Och om en klass implementerar vissa metoder, så "stöder den exekvering" av vissa kommandon. Vad vinner vi på att kombinera metoder till ett gränssnitt?

1) Varje gränssnitt , precis som en klass , har ett unikt namn. Båda parter kan vara 100 % säkra på att den andra parten stöder det exakta gränssnittet de känner till och inte något liknande gränssnitt.

2) Varje gränssnitt lägger vissa restriktioner på en klass som kommer att stödja det. Klassen (dess utvecklare) bestämmer vad den ska göra när metoderna som ärvs från ett gränssnitt anropas, men resultatet bör ligga inom gränserna för rimliga förväntningar. Om vi ​​beordrar en hund att "sitta" och sedan rullar den runt på plats i 5 minuter och sedan sitter, då stödjer den gränssnittet. Men om den istället tar dig i benet kan vi knappast säga att den stöder gränssnittet. Att köra kommandot gav inte det förväntade resultatet.

Låt oss säga att du och dina vänner skriver ett datorspel. Och du har fått i uppdrag att programmera beteendet för en karaktär. En av dina kollegor har redan skrivit kod för att visa alla tecken på skärmen. En andra kollega, som ansvarar för att spara spelet på disk, har skrivit kod för att spara alla spelobjekt till en fil. Var och en av dem skrev mycket kod och skapade ett gränssnitt för att interagera med den koden. Det kan till exempel se ut så här:

interface Saveable
{
 void saveToMap(Map<String, Object> map);
 void loadFromMap(Map<String, Object> map);
}

interface Drawable
{
 void draw(Screen screen);
}

class PacMan implements Saveable, Drawable
{
…
}

Med andra ord, för att stödja alla gränssnitt (grupp av gränssnitt), måste din klass:

1) Ärva dem

2) Implementera de metoder som anges i dem

3) Metoderna måste göra vad de var avsedda att göra.

Då kan resten av programmets kod, som inte vet något om din klass och dess objekt, fungera med din klass.

"Varför kan koden inte veta något om min klass?"

"Låt oss säga att du tog koden från ett program som någon skrev för ett år sedan. Eller antar att dina vänner köpte/licensierade spelmotorn från någon annan. Du har fungerande kod för spelet. Tusentals objekt som interagerar med varandra. Och de kan enkelt interagera korrekt med dina objekt om du får den interaktionen att ske genom gränssnitt som dina klasser har implementerat korrekt."

"Långt ut! Jag visste inte att det var möjligt."

"Alla stora projekt fungerar så här. Folk slutade skriva från grunden för länge sedan."

Människor uppfinner inte heller matematiken och alfabetet varje gång. Istället studerar de allt som uppfanns före dem.