Grensesnitt finnes for å støtte spesifikk atferd

"Hei, Amigo! I dag vil jeg gjerne fortelle deg grunnene til at grensesnitt eksisterer. Du hører ofte at en bestemt klasse, objekt eller enhet støtter et bestemt grensesnitt. Hva betyr det å støtte et grensesnitt ? "

I en bredere forstand er ethvert grensesnitt en mekanisme for at noe kan samhandle med noe annet. For eksempel er en TV-fjernkontroll et eksternt grensesnitt. En hund forstår og utfører kommandoer, noe som betyr at hunden støtter et stemmegrensesnitt (kontroll). For å oppsummere det hele kan vi si at et grensesnitt er en standardisert måte for to ting å samhandle på, hvor begge parter kjenner standarden. Når en person sier til en hund å "sitte", er hans eller hennes kommando en del av et «dog voice-control interface», og hvis hunden adlyder kommandoen, så sier vi at hunden støtter grensesnittet.

Så det er i programmering. Metoder er handlinger utført på et objekt, på dets data. Og hvis en klasse implementerer visse metoder, så «støtter den utførelsen» av visse kommandoer. Hva får vi ved å kombinere metoder til et grensesnitt?

1) Hvert grensesnitt , akkurat som en klasse , har et unikt navn. Begge parter kan være 100 % sikre på at den andre parten støtter det eksakte grensesnittet de kjenner og ikke et lignende grensesnitt.

2) Hvert grensesnitt pålegger visse begrensninger for en klasse som skal støtte det. Klassen (utvikleren) bestemmer hva den skal gjøre når metodene som er arvet fra et grensesnitt kalles, men resultatet bør være innenfor rimelige forventninger. Hvis vi beordrer en hund til å "sitte" og så ruller den rundt på plass i 5 minutter og deretter sitter, så støtter den grensesnittet. Men hvis den i stedet griper deg i benet, kan vi neppe si at den støtter grensesnittet. Utførelse av kommandoen ga ikke det forventede resultatet.

La oss si at du og vennene dine skriver et dataspill. Og du har fått i oppdrag å programmere oppførselen til én karakter. En av kollegene dine har allerede skrevet kode for å vise alle tegnene på skjermen. En annen kollega, som er ansvarlig for å lagre spillet på disk, har skrevet kode for å lagre alle spillobjekter til en fil. Hver av dem skrev mye kode og laget et grensesnitt for å samhandle med den koden. For eksempel kan det se slik ut:

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 andre ord, for å støtte et hvilket som helst grensesnitt (gruppe av grensesnitt), må klassen din:

1) Arve dem

2) Implementer metodene som er deklarert i dem

3) Metodene må gjøre det de var ment å gjøre.

Da kan resten av programmets kode, som ikke vet noe om klassen din og dens objekter, fungere med klassen din.

"Hvorfor kan ikke koden vite noe om klassen min?"

"La oss si at du tok koden fra et program som noen skrev for et år siden. Eller anta at vennene dine kjøpte/lisensierte spillmotoren fra noen andre. Du har fungerende kode for spillet. Tusenvis av objekter som samhandler med hverandre. Og de kan enkelt samhandle riktig med objektene dine hvis du får den interaksjonen til å skje gjennom grensesnitt som klassene dine har implementert riktig."

"Langt ute! Jeg visste ikke at det var mulig."

"Alle store prosjekter fungerer slik. Folk sluttet å skrive fra bunnen av for lenge siden."

Folk finner heller ikke opp matematikken og alfabetet på nytt hver gang. I stedet studerer de alt som ble oppfunnet før dem.