Hvorfor bruge interfaces i java

Interfacen kræver endda at man implementerer alle dens metoder hvis man vil bruge den.. hvorfor?

Pointen er at abstrahere væk fra en specifik klasse, en bestemt måde at gøre det på, fra det du faktisk ønsker muligt. Hvis du giver mig et objekt som implementerer InterfaceTest, så forventer jeg at kunne kalde både setSize og getSize. Det er den abstraktion som InterfaceTest giver mig og kompileren håndhæver den. Jeg kan ikke vide at kun halvdelen er implementeret og hvis jeg kunne så kan jeg højst sandsynligvis ikke bruge den siden man typisk har brug for alle Interface's metoder.

Pointen er at undgå kobling samt at få mere abstraktion. Du har du et meget lille eksempel, men i større projekter kan det have stor betydning. I din main skriver du TestInterface1. Forestil dig nu at du gerne vil implementere setSize og getSize på en anden måde. Så skulle du enten rette i TestInterface1 klassen (som måske stadig skal bruges som den er et andet sted) eller lave en ny klasse med samme metoder og ændre det alle de steder der bruges TestInterface1.

For et software bibliotek ville dette måske være endnu mere problematisk, siden folk måske har kompileret kode opad det gamle navn.

Til 1 interface kan du have N klasser. Ved at bruge klassenavnene skal du ændre flere steder hvis du ændrer på koden, med et interface skal du kun ændre det de steder du instantierer.

Det eksempel du kommer med er heller ikke så god til at vise fordelene. Normalt beskriver et Interface's metoder adfærd, men ikke hvordan det skal gøres. getSize og setSize, kan snævert beskrives som adfærd, og det 'lækker' detaljer om hvordan en klasse skal implementeres i stedet for hvorfor. Til en datastruktur kan getSize måske gå an men ikke setSize.

Her er et eksempel som jeg mener bedre viser styrkerne:

 public Interface GameObject {
     public void update();
     public void render(Graphics g);
 }
 
 public class Man implements GameObject {
     //...... Andre metoder, og instansvariabler
     //Som eatFood og move
     public void update() {
         int food = World.getFoodInPos(this.getPos());
         eatFood();
         move();
     }
 
     public void render(Graphics g) {
         //Tegn ben, arme, etc..
         g.drawLine(.....);
     }
 }
 
 public class Car implements GameObject {
 
     public void update() {
         if (engineOn) {
             fuel -= fuelConsumptionRate;
         }
         if (fuel <= 0) {
             fuel = 0;
             engineOn = false;
         }
         //etc..
     }
 
     public void render(Graphics g) {
         //Tegn hjul, karosseri, etc..
     }
 }

Forestil dig et spil. Interfacet beskriver ikke implementation, men adfærd. Ethvert game objekt skal håndtere sin egen game update og rendering ved brug af et Graphics objekt g. Du kunne have gjort det samme med en (abstrakt) klasse men det giver typisk store begrænsinger i sprog som Java og C# som har single-inheritance, siden så kan dine klasser ikke arve fra noget andet. Men det gør også sådan noget her muligt på en renere måde:

 public class GameEngine {
     //Instansvariabler etc..
     public void Main() {
         while (runGame) {
             for (GameObject go : getAllObjects()) {
                 go.update();
                 go.render();
             }
         }
     }
 }

Uden en fælles interface eller klasse, ville dette ikke være muligt uden at checke typen på 'go' hele tiden og så caste til den rigtige type, hvilket hurtigt bliver ukontrollerbart når man tilføjer fly, aliens, bygninger og andre klasser.

Det smarte ved at bruge interfaces(hvis de bliver brugt rigtigt, og folk kan finde ud af at bruge dem ).. Er at du kan lave et API, som nogle andre programmører kan kode op imod. Det kan bl.a. bruges til at strukturerer hvilke metoder en bestemt klasse skal have, og så kan du kode op imod interfacet, uden at tænke på koden der ligger bag den, som din ven eller en anden programmør er igang med at lave, imens du har tid til at kigge på nogle andre dele af koden.
Når man gør det på denne måde undgår man at skulle kende til hele koden, for at vide, hvad de enkelte metoder og klasser står til ansvar for. Så man kan vel enligt godt sige at interfaces er en måde at strukturerer sine programmer på.

Et andet eksempel hvorfor interfaces er smarte er iterator, de bruges i foreach løkker. De virker ved at man tjekker om en klasse, man vil køre igennem, implementer Iterable<T> (et generisk interface) som giver en klasse som implementer interfacet Iterator<E>. Det bliver brugt i foreach løkker til at gå igennem f.eks. en list. Foreach løkken ved ikke hvordan listen er konstrueret, kun at hvis den kalder metoderne next(), og hasNext() så er der en klasse implementer metoderne. På den måde du lave din egen list som så implementer Iterable og Iterator, så du kan bruge foreach. Det ville ikke være muligt uden et Interface. Der er rigtigt mange andre eksempler på det hvis man læser om design patterns.

Tak for jeres svar.. hjalp mig rigtig godt på vej !