Interfaces bestaan om specifiek gedrag te ondersteunen

"Hallo, Amigo! Vandaag wil ik je de redenen vertellen waarom interfaces bestaan. Je hoort vaak dat een bepaalde klasse, object of entiteit een bepaalde interface ondersteunt. Wat betekent het om een ​​interface te ondersteunen ? "

In bredere zin is elke interface een mechanisme waardoor iets met iets anders kan interageren. Een afstandsbediening van een tv is bijvoorbeeld een externe interface. Een hond begrijpt en voert commando's uit, wat inhoudt dat de hond een spraak(besturings)interface ondersteunt. Samenvattend kunnen we zeggen dat een interface een gestandaardiseerde manier is waarop twee dingen met elkaar kunnen communiceren, waarbij beide partijen de standaard kennen. Wanneer een persoon een hond vertelt om te "zitten", maakt zijn of haar commando deel uit van een "dog voice-control interface", en als de hond het commando gehoorzaamt, dan zeggen we dat de hond de interface ondersteunt.

Zo zit het in de programmering. Methoden zijn acties die worden uitgevoerd op een object, op zijn gegevens. En als een klasse bepaalde methoden implementeert, dan "ondersteunt het de uitvoering" van bepaalde commando's. Wat winnen we door methoden te combineren in een interface?

1) Elke interface heeft , net als een klasse , een unieke naam. Beide partijen kunnen er 100% zeker van zijn dat de andere partij de exacte interface ondersteunt die ze kennen en niet een vergelijkbare interface.

2) Elke interface legt bepaalde beperkingen op aan een klasse die deze gaat ondersteunen. De klasse (zijn ontwikkelaar) beslist wat hij zal doen wanneer de methoden die zijn geërfd van een interface worden aangeroepen, maar het resultaat moet binnen de grenzen van redelijke verwachtingen vallen. Als we een hond opdracht geven om te "zitten" en hij rolt dan 5 minuten op zijn plaats rond en gaat dan zitten, dan ondersteunt hij de interface. Maar als het je in plaats daarvan bij je been grijpt, kunnen we nauwelijks zeggen dat het de interface ondersteunt. Het uitvoeren van de opdracht leverde niet het verwachte resultaat op.

Stel dat jij en je vrienden een computerspel schrijven. En je hebt de opdracht gekregen om het gedrag van één personage te programmeren. Een van je collega's heeft al code geschreven om alle karakters op het scherm weer te geven. Een tweede collega, die verantwoordelijk is voor het opslaan van het spel op schijf, heeft code geschreven om alle spelobjecten in een bestand op te slaan. Elk van hen schreef veel code en maakte een interface voor interactie met die code. Het kan er bijvoorbeeld zo uitzien:

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
{
…
}

Met andere woorden, om elke interface (groep interfaces) te ondersteunen, moet uw klasse:

1) Erf ze

2) Implementeer de methoden die erin worden verklaard

3) De methoden moeten doen waarvoor ze bedoeld zijn.

Dan kan de rest van de programmacode, die niets weet over uw klasse en zijn objecten, met uw klasse werken.

"Waarom weet de code niets over mijn klas?"

"Stel dat je de code hebt overgenomen van een programma dat iemand een jaar geleden heeft geschreven. Of stel dat je vrienden de game-engine van iemand anders hebben gekocht of in licentie hebben gegeven. Je hebt werkende code voor de game. Duizenden objecten die met elkaar communiceren. En ze kan eenvoudig correct communiceren met uw objecten als u die interactie tot stand brengt via interfaces die uw klassen correct hebben geïmplementeerd."

'Ver weg! Ik wist niet dat dat mogelijk was.'

"Alle grote projecten werken zo. Mensen zijn al lang geleden gestopt met schrijven."

Mensen vinden wiskunde en het alfabet ook niet elke keer opnieuw uit. In plaats daarvan bestuderen ze alles wat vóór hen is uitgevonden.