[c#] interfaces

[hopakee]

Kan iemand mij vertellen wat het nut is van interfaces binnen c#
het enige waarmee ik het kan vergelijken is een header file in c++, maar
wat is hierdan het nut van? binnen c#

[whoami]

Neem eens een boek en lees eerst eens iets over interfaces. Wat ze zijn enzo.

Dmv een interface kan je bepaalde functionaliteit aan een klasse toevoegen. De functies die in de interface gedefinieerd zijn, moet je dan in die klasse gaan uitwerken.

[Zoijar]

Ik zou eerder het woord "opleggen" gebruiken dan "toevoegen"

[hopakee]

Heb ik gedaan, ik heb gelezen wat een interface is en er een geimplementeerd,
maar ik zie het nut niet om een interface te gebruiken.
je kan bepaalde functionaliteit toevoegen aan je eigen class maar je moet 'm nog wel zelf implementeren.

m.a.w. Waarom zou je ervoor kiezen om je class af te leiden van een interface

[Verwijderd]

Zodat een ander stuk code die totaal niets af weet van jouw klasse maar wel iets weet van die interface jouw code toch kan gebruiken?

[hopakee]

dus het is om een soort standaard af te dwingen voor het gebruik van basis functionaliteit binnen een class??

[Alarmnummer]

Een interface is een uitermate krachtig mechanisme waardoor je niet meer vast zit aan soms onmogelijke multiple overervingen

code:

public class Persoon{
    private String _naam;
    public String getNaam(){return _naam;}
}

public class Appel{
    private int _gewicht;
    private int getGewicht(){return _gewicht;}
}

public class AppelPersoon extends Appel,Persoon{
}

Het bovenstaande voorbeeld gaat dus niet lukken, omdat multiple inheritance niet ondersteunt wordt.

oplossing dmv interfaces:

code:

public interface Persoon{
   public String getNaam();
}

public class PersoonImpl implements Persoon{
   private String _naam;
   public String getNaam(){return _naam;}
}

public interface Appel{
    public int getGewicht();
}

public class AppelImpl implements Appel{
    private int _gewicht;
    public int getGewicht(){return _gewicht;}
}

public AppelPersoon implements Appel,Persoon{
    private Appel _appel = new AppelImpl();
    private Persoon _persoon = new PersoonImpl();

   public int getGewicht(){
       return _appel.getGewicht();
   }

   public String getNaam(){
       return _persoon.getNaam();
   }
}

En verder kan dus dus de implementatie (class) volledig ontkoppelen van de definitie (interface) en je beschrijft in principe nog een minimalere definitie dan een c++ class.

[xos]

Een interface verteld hoe een classe eruit moet komen te zien die zo'n interface implementeerd.

En wat alarm# ook zeg.

[LordLarry]

Juist. Met interfaces geef je een klasse een bepaalde functionaliteit. Bijvoorbeeld ISortable. Die moet je dan wel zelf implementeren, maar iedereen die met ISortable kan werken kan jouw klasse dus gebruiken om via die interface iets te sorteren. Je zou daar ook een ingewikkelde klasse structuur met overerving voor kunnen bedenken, maar dit is veel soepeler.

Verder kunnen klassen meerdere interfaces tegelijk ondersteunen.

Behalve C++ kunnen veel programmeer talen niet van meer als 1 klasse afleiden (multiple inheritance) en zo kunnen ze dit wel een beetje simuleren.

[Alarmnummer]

hopakee schreef op 12 augustus 2002 @ 13:58:
Heb ik gedaan, ik heb gelezen wat een interface is en er een geimplementeerd,
maar ik zie het nut niet om een interface te gebruiken.
je kan bepaalde functionaliteit toevoegen aan je eigen class maar je moet 'm nog wel zelf implementeren.

m.a.w. Waarom zou je ervoor kiezen om je class af te leiden van een interface

Omdat je dus niet meer vast zit aan een bepaalde implementatie en andere compontenten dus praten met een 'verwachting' (interface dus), en wat die implementatie (class) is is dus voor de mensen die er mee praten onbelangrijk.

Stel dat je de volgende interface hebt:

code:

public interface Verkoper{
    public int getKorting();
}

en de volgende 2 classes

code:

public class RotVerkoper implements Verkoper{
    public int getKorting(){return -10;}
}

public class VriendelijkeVerkoper implements Verkoper{
    pubic int getKorting(){return 80;}
}

En een klant gaat iets met een verkoper doen:

code:

public class Klant{

     public void doIets(Verkoper v){
          int korting = v.getKorting();
     }
}

Dan hangt het dus af van welke verkoper hij krijgt hoeveel korting hij krijgt. Maar bij de klant hoeft daar dus geen rekening mee gehouden worden. Hij weet dat ij met een een Verkoper praat, en wat daar de implementatie van is is onbelangrijk.

Je zou dit ook op kunnen lossen met een abstracte class Verkoper, maar dan moet je dus overerven van Verkoper en dit kan grote problemen opleveren met je class hierarchie.

Ik ontwerp op dit moment alles vanuit interfaces en de implementaties die hangen er wel achter zonder dat iemand daar iets mee te maken heeft. Hierdoor krijg je een gigantisch stuk bewegingsvrijheid.

[Zoijar]

Het is ook wel handig als je met een team ontwikkeld. Programmeur A kan dan zijn interface met pre en post condities aan programmeur B geven. Die kan dan op zijn beurt gewoon iets ontwikkelen dat deze interface gebruikt zonder zich druk te maken over hoe Programmeur A nou precies die interface implementeert.

[Verwijderd]

Interfaces definieren .... een interface, dus classes die de interface implementeren, bieden dus die interface aan, een gebruiker van een instance van zo'n class WEET dan dat die methods er zijn, en kan bv dmv de interface naar zo'n object kijken.

Wordt bv gebruikt bij het uniform maken van ADO.NET code: je gebruikt IDBConnection ipv SqlConnection of OleDBConnection (of MySQLConnection), en creeert in een enkele routine een instance van het gewenste object, bv een SqlConnection object, terwijl de code gewoon dmv de interface IDBConnection (die wordt geimplementeerd door SqlConnection en andere *Connection classes) het object gebruikt en niet weet of dit een SqlConnection of een OracleConnection object is, want de interface definitie bepaalt dat al die objecten dezelfde methods implementeren zodanig dat ze dezelfde functionaliteit leveren.

Als je nou een discussie over Abstract classes vs Interfaces was gestart...

[Soultaker]

Hier wil ik eigenlijk twee dingen aan toevoegen.

Ten eerste bestaat er onderscheid tussen het erven van interface en implementatie, wat twee verschillende concepten zijn (zoals hierboven is uitgelegd).

Zoals gezegd, ondersteunen C# en Java uitsluitend het ervan van een enkele implementatie, maar van verschillende interfaces. Andere programmeertalen (in het bijzonder C++) ondersteunen ook het erven van meerdere implementaties, weer andere programmeertalen (zoals bijvoorbeeld Smalltalk) doen niet aan interfaces en ondersteunen alleen het erven implementaties.

Het is overigens niet zo dat alleen het ervan van meerdere implementaties ambiguiteiten kan veroorzaken; dit is eigenlijk net zo goed het geval met het erven van interfaces. Het grote verschil met het erven van interfaces is echter, dat methoden met dezelfde argumenten en hetzelfde resultaat in de implementatie door eenzelfde methode geimplementeert worden.

Dit is zowel een sterk als een zwak punt van het erven van interfaces: als de door verschillende interfaces opgelegd functionaliteit overlapt, hoeft niet onnodig een extra methode te worden opgenomen in de implementatie. Aan de andere kant, als twee ongerelateerde interfaces een methode van hetzelfde type verwachten, is het onmogelijk deze twee onafhankelijk van elkaar in dezelfde implementatie uit te werken.

Ten tweede wil ik even opmerken dat Alarmnummer's voorbeeld uitsluitend het concept van erven zelf demonstreert, maar niet de situatie waarin overerving gebruikt hoort te worden. Dit is namelijk uitsluitend zinvol, wanneer de nieuwe klasse andere functionaliteit biedt dan de basisklasse. Wanneer het verschil tussen klassen uitsluitend een gedrag in waarde is (een andere kortingspercentage in het voorbeeld) hoort deze variatie uitgedrukt te worden in een attribuut van de Verkoper klasse. De reden hiervoor is dat het niet praktisch is om een onnodig uitgebreide ervingsstructuur te hebben en het erven (van zowel interfaces als implementatie) alleen moet gebeuren als het noodzakelijk is.

[LordLarry]

Soultaker schreef op 12 augustus 2002 @ 15:00:
Het is overigens niet zo dat alleen het ervan van meerdere implementaties ambiguiteiten kan veroorzaken; dit is eigenlijk net zo goed het geval met het erven van interfaces. Het grote verschil met het erven van interfaces is echter, dat methoden met dezelfde argumenten en hetzelfde resultaat in de implementatie door eenzelfde methode geimplementeert worden.

Dit is zowel een sterk als een zwak punt van het erven van interfaces: als de door verschillende interfaces opgelegd functionaliteit overlapt, hoeft niet onnodig een extra methode te worden opgenomen in de implementatie. Aan de andere kant, als twee ongerelateerde interfaces een methode van hetzelfde type verwachten, is het onmogelijk deze twee onafhankelijk van elkaar in dezelfde implementatie uit te werken.

code:

  IAap = interface
    function Letters: String;
  end;

  INoot = interface
    function Letters: String;
  end;

  TAlphabet = class(TInterfacedObject, IAap, INoot)
  public
    function Letters: String;
  end;

Kan inderdaad wel gemakkelijk.

Wat jij zegt dat niet kan kan Delphi wel. Dus wel twee verschillende implementaties aan 1 methode naam kan geven binnen 1 klasse.

code:

  TAlphabet = class(TInterfacedObject, IAap, INoot)
  private
    function AapLetters: String;
    function NootLetters: String;
  public
    function IAap.Letters = AapLetters;
    function INoot.Letters = NootLetters;
  end;

[ Voor 0% gewijzigd door LordLarry op 12-08-2002 15:20 . Reden: tevroeg op versturen gedrukt ]

[Glimi]

Alarmnummer schreef op 12 augustus 2002 @ 14:19:
Een interface is een uitermate krachtig mechanisme waardoor je niet meer vast zit aan soms onmogelijke multiple overervingen

code:

public class Persoon{
    private String _naam;
    public String getNaam(){return _naam;}
}

public class Appel{
    private int _gewicht;
    private int getGewicht(){return _gewicht;}
}

public class AppelPersoon implements Appel,Persoon{
}

[knip]

Nou dit gaat niet altijd op he Alarmnummer , dat multiple inheritance altijd op te lossen is dmv interfaces

code:

public interface Persoon{
    public static final Soort _soortNaam = new Soort( "Zoogdier" );
    public String getNaam();
}

public interface Appel{
    public static final Soort _soortNaam = new Soort( "Vrucht" );
    private int _gewicht;
    private int getGewicht();
}

/* Bwappa! Abiguïteit */
public class AppelPersoon extends Appel,Persoon{
}

Natuurlijk beschrijft dit een waardeloos design bij dit voorbeeld, maar het idee is duidelijk. Multiple inheritance dmv interfaces kan problemen geven als beide interfaces een static variable bevatten met dezelfde naam. Tja, waarom mogen interfaces eigenlijk vars bevatten?

Op dit punt na vind ik interfaces om van te

[hopakee]

thanks allemaal het is een stuk duidelijker nu.