Wat is het nut van een interface?

[EdjeCageman]

beste mensen,

Ik ben nog wat dieper gaan programmeren, en krijg nu te maken met interfaces en overerving. Nou, overerving kan me wel indenken (de blauwdrukken van een methode) wat het nut ervan is, klasse a maakt gebruik van methodes besproken in klasse b.

Maar wat is het nut van Interfaces? De 'blauwdrukken' van verschillende klasse. Maar waarom kan je niet gewoon de klasse copie - pasta en de methode's aanpassen? Of denk ik te smal?

 

[Parnassian]

Interfaces worden voor vele dingen gebruikt, zoals de MouseListener interface en zo ook de KeyListener interface, waar je gemakkelijk listeners aan bijvoorbeeld een applet kan toevoegen. Een interface kan je in elke class implenteren en daarom ook makkelijk van elke class uit laten voeren, dit is veel handiger dan steeds een aparte methode aanmaken die een andere class aanroept.

 

[wampier]

Interfaces specificeren wel uh interfaces Een interface kun je als een generieke aansturing zien. Andere klassen kunnen die algemene aansturing gebruiken om op een standaard manier data terug te geven. Dit kan interessant zijn als je niet hoeft te weten wat de achterliggende implementatie is.

Stel je maakt een interface met een boolean: AAN/UIT

Deze interface kan geïmplementeerd zijn op:

koffiezetapparaat
schuurmachine
auto
etc. etc.

Met deze implementatie kun je een object altijd aanzetten, zonder dat je hoeft te weten wat je aanzet. Omgekeerd kun je op een uniforme manier altijd nagaan of aan apparaat aan of uit staat en kun je door een grote collectie ongerelateerde classes lopen om de status te bepalen.

Voor eigen gebruik zul je dit niet zo snel gebruiken. Inheritence daarentegen kan zeer krachtig zijn ook voor kleinere projecten

 

[EdjeCageman]

Ja maar als je een koffieautomaat aanzet dan doe je toch (uitgaand dat automaat een interface is)
automaat koffie = new koffieautomaat();
dus je weet toch wat je aanzet? :S

Wat maakt het handiger dan een methode/klasse te maken met:
koffieautomaat koffie = new koffieautomaat();


Kijk wat ik er niet aan snap je hebt dan de volgende classe:

public class automaatsim
{
public static void main(String[] args)
{
 automaat koffie = new koffieautomaat()
}
}

public interface automaat
{
public void zetaan()
public void zetuit()
}

public class koffieautomaat
{
public koffieautomaat()
{
   //doe iets
}

public void zetaan()
{
system.out.println("Aangezet");
}

public void zetuit()
{
system.out.println("shuting down");
}
}

Waarom is het handiger om dan een interface "automaat" te gebruiken ipv gewoon gelijk koffieautomaat aan te roepen.

 

[wampier]

Omdat je nu een niveau te hoog zit

Je voorbeeld zou moeten zijn:

Class automaat
{
  automaat dingen
}

public class koffiezetter extends automaat
{ 
  //automaat dingen heb je al overgenomen, uitbreiden met:
  koffiespecifieke dingen
}

Dat is standaard inheritence. Je hebt een generieke class automaat, waarvan je de "kinderen" specifieker maakt. In dit geval is het specifieke "kind" van automaat een koffiezetter. Alle variables en functions van automaat erf je automatisch over. Als 'automaat' een (publieke) variabele "gewicht" heeft, heeft 'koffiezetter' die ook, zonder dat je die hoeft te definiëren in 'koffiezetter'.

Voordeel hiervan is dat als veel van je objecten overeenkomsten hebben, dat je die niet in elke class hoeft aan te passen.

Interfaces werkt wat anders.

Stel je hebt twee hoofdclasses, automaat en automobiel. Beide hebben ook een "kind"-object (bijvoorbeeld): koffiezetter en volkswagen. Beide "kinderen" zijn andere objecten en ze hebben verder ook weinig overeenkomsten. Ze kunnen echter wel beide aan en uit gezet worden. Door een interface AAN/UIT te definiëren en die aan beide (hoofd)objecten toe te voegen kun je een standaard manier creëren om die objecten aan en uit te zetten ook al hebben ze verder niets met elkaar te maken.

Je zou dan iets kunnen maken zoals:

function alles_uitzetten
{
for each object{object.zetuit()}
}

Zonder te hoeven weten wat het object is, of hoe het object het uitzetten intern implementeert.

 

[EdjeCageman]

Oke, dus als ik het goed begrijp even simpel gezegd het is gewoon een standaardisatie, van klasse die dezelfde methode's hebben.
Maar eigenlijk kan je dan overal een Interface van maken als je wilt?

 

[wampier]

Het is vooral handig als je iemand anders zijn code moet gebruiken of importeren. Zolang je een standaard interface gebruikt hoef je je geen zorgen te maken over de implementatie in de eigenlijke code.

Maar zoals ik al in mijn eerste post aangaf, als je met eigen projecten bezig bent zul je vooral inheritance gebruiken en vaak geen interfaces.

 

[EdjeCageman]

oke dus kijk ik even naar reallife, dan is een stopcontact een interface? Komt er een engelsman moet hij zijn code (lees koppelstuk) schrijven naar ons stopcontact?

 

[wampier]

Er zijn twee kanten en daarmee kan je de analogie wat verder uitbouwen:

Apparatuur heeft de interface "stroom" en degene die het apparaat wil gebruiken moet de juiste plug maar schrijven. Voor het apparaat is het namelijk van generlei belang hoe het stopcontact eruit ziet. Ook 230/220/110 V is eigenlijk vaak niet van belang. De adapter (precies het juiste woord hier in de letterlijke zin: "aanpasser") zorgt er dus voor dat de interface "stopcontact" van het lichtnet en de interface "stroom" van het apparaat met elkaar praten.

Vanuit het lichtnet gezien is de interface inderdaad het stopcontact. Iedereen die het lichtnet wil gebruiken moet dus op de interface "stopcontact" passen. De zekering, kabeldikte, veiligheid d.m.v. aardlekschakelaar e.d. is voor de gebruiker van de interface "stopcontact" niet gekend en ook niet belangrijk, zolang je er maar van uit kan gaan dat je alles dat je in de interface prikt stroom geleverd krijgt vanuit het lichtnet.

Veel code en kennis in grote projecten zit in het schrijven van de adapters tussen interfaces. Drivers zijn bijvoorbeeld adapters tussen interfaces (standaard hardware laag naar standaard OS abstraction laag).

 

[EdjeCageman]

En nou even waarom ik hierover begon
Ik heb op dit moment een panel met een aantal stoelen , en er is ook nog een 2de zaal met een ander aantal stoelen.
(er zijn nog 2 andere zalen maar die hebben dezelfde layout als zaal 1 en 2 dus kan gewoon nog een object aanmaken van die)
Deze stoelen kunnen aan uitgezet worden en/of bezet zijn.

In de toekomst zou het dus ook zo kunnen zijn dat er een 3de zaal (of zelfs een 4de, 5de, etc) komt.

Is hier een interface makkelijker voor? Zo ja, hoe moet ik dit dan maken???

 

[Parnassian]

Ik denk niet dat een interface dit makkelijker maakt.

Het beste lijkt me een class Stoel te maken met een enum, en in de zaal Class een arraylist met stoelen

import java.util.ArrayList;


public class Zaal {
	private ArrayList<Stoel> stoelen = new ArrayList<Stoel>();
	private int aantalStoelen = 0;
	
	public Zaal(int aantalStoelen) {
		this.aantalStoelen = aantalStoelen;
		for(int teller = 0; teller < aantalStoelen; teller++) {
			stoelen.add(new Stoel(Stoel.Status.VRIJ));
		}
	}
	
	public Stoel krijgStoel(int index) {
		return stoelen.get(index);
	}
	
	public int aantalStoelen() {
		return aantalStoelen;
	}

}

public class Stoel {
	
	private Status status = null;
	
	public Stoel(Status status) {
		this.status = status;
	}
	
	static enum Status {
		UIT, VRIJ, BEZET
	}
	
	public void setStatus(Status status) {
		this.status = status;
	}
	
	public Status krijgStatus() {
		return status;
	}
	
	

}

 

[EdjeCageman]

zo bestond ie ook al

't gaat om 't panel op het 'hoofdpanel' te plaatsen. Dus ik maak 2 panels aan kleine/grote zaal. Maar maakt een interface tussen het hoofdpanel en het zalenpanel