fordel ved interface

Jeg vil næsten kalde et interface for en slags huskeliste eller en slags kontrakt...

så man medtager alle metoder i sit interface og ikke glemmer nogle.

Et interface bygges op således
http://javabog.dk/OOP/kapitel12.jsp

kan ikke se hvordan du ellers ville lave det:)

fordele er som sagt at hvis man arbejde flere om et projekt så er det lettere ikke at glemme enkelte metoder, men man er tvunget til at implementere dem alle..

ulemper.. ja så meget har jeg heller ikke arbejdet med dem:)

fordelen ved at interface er at man kan skifte implementationen udelukkende ved at rette
i instantieringen

Hvis du bruger:

ArrayList al = new ArrayList();
m(al);

hvor

public void m(ArrayList al) {

så skal du rette en million steder for at skifte fra ArrayList til en anden List

med

List l = new ArrayList();
m(l);

hvor

public void m(List l) {

så skal du kun rette et sted (fra new ArrayList til new NogetAndet)

Et andet godt eksempel på det er JDBC klaserne i java.sql.*, hvor alt er
interfaces således at de enkelte database leverandører kan lave deres egen
implementation, men din Java kode ser ens ud (bortset fra connection URL og
loadet driver)

Der er ikke nogen specielle ulemper (bortset fra at man får en
source code fil mere), dog er der naturligvis ikke alle tilfælde
hvor det giver mening at bruge interfaces.

Og man kan ikke bruge static i interfaces !

og det er altså ikke i modstrid med kalps forklaring

hvad er et interface ? en kontrakt om hvad en klasse skal implementere

hvorfor er det smart ? fordi man kan skifte implementationen uden at påvirke
koden (hvilket kun er muligt fordi man ved at alle implementationer
overholder kontrakten !)

kalp - kap 12 under javabog.dk er sådan set let at forstå, men jeg syntes ikke at jeg stadig forstår hvad fordelen er ved at lave deciderede interface klasser.

Arne - jeg er helt ude på lars ... mark, hvad angår det du har skrevet..

jeg kan stadig ikk se hvornår jeg under min kodning burde lave interface klasser og hvornår jeg ikke burde gøre det

du skal bruge et interface når du laver en løsning, hvor funktionaliteten vil
være konstant eller ihvertfald voksende for evigt men du vil gerne have
mulighed for at løse opgave smartere senere uden at der skal ændres i kode
som bruger din funktionalitet

Og faren ved interfaces er at du risikere navnesammenfald der ikke bliver opdaget

interface Punkt {
    public int getX();
    public int getY();
}
interface Ligning {
    public void setLigning( String lign );
    public int getX();
}
class KlasseDerBliverNogetBæ implements Punkt, Ligning {
    int x,y;
    public int getX() {  // denne metode kaldes uanset hvilket interface du tror du bruger
        return x;
    }
hvis du *også* prøver at lave en anden getX metode (til ligningen) får du navnesammenfald fordi signaturen er ens, hvis ikke kan der gå meget lang tid før fejlen bliver opdaget.

ja

men er fejlen at Java ikke giver warning på det eller er fejlen at det er et håbløst
design udfra en OO synsvinkel (noget kan ike både være et punkt og en ligning på
samme tid)

ved fornuftigt OO design og fornuftigt valg af metodenavne så bør risikoen
være minimal

Tid at få afsluttet spørgsmålet ?

Og et svar fra mig