Hej,

jag håller att utvecklar en web-applikation m h a C# och använder mig av ett skiktat ramverk (skrivet av en konsult) byggt på objektorientering och som bl a använder sig av Interface.

Jag har dock inte riktigt fått klart för mig vad den stora nyttan är med att använda interface, att m h a arv ärva klasser har jag koll på och jag ser en stor nytta med detta. Men jag har faktiskt inte stött på ngn som på ett bra sätt kan förklara vad jag skall ha interface till och då blir jag lite frågande till det. Det är ju en viktig del av objektorienteringen så jag inser att det är ngt bra och genomtänkt men jag vill ha en bra förklaring, gärna med exempel.

Ngn har förklarat det som att det är ngn form av kontrakt som talar om att en klass som implementerar ett visst interface måste implementera det som är specat i interfacet, ok, men vad är nyttan med det?

Vad är fördelen med att använda interface iställer för att använda klasser som man ärver från?

<b>Vad är fördelen med att använda interface iställer för att använda klasser som man ärver från?</b>

Jag har en app som dynamiskt laddar ett antal moduler. Modulerna är vitt skilda och kan göra en massa olika saker och olika personer/roller/marknader får se olika moduler. Från mitt program så skiter jag i vad modulerna gör, jag laddar dem och använder de metoder/properties som ett interface deklarerar. T ex så vill jag i mitt Interface ha metoderna DoStuff och Save, då är det enda jag behöver bry mig är att modulerna implementerar DoStuff & Save enligt interfacet och mitt program som laddar dem behöver bara känna till vilka metoder som finns enligt interfacet.


tex om jag har alla moduler laddade dynamiskt in i en araylist skulle jag kunna göra så här:
<code>
//MyInterface.IModule är mitt interface med två metoder
foreach(MyInterface.IModule _im in ListOfModules)
{
_im.DoStuff();
_im.Save();
}
</code>
Hur skulel jag lösa det om de inte implementerar interface för att speca upp vilka funktioner som skall finnas?

OK, det köper jag, här hade det ju självklart inte gått att ärva från en annan klass.

Men då är alltså interfacet mer som ett slags kontrakt för de klasser som implementerar interfacet? Dvs att klass A och klass B implementerar interface C (som bla deklarerar metoden Save och Get) och då "vet" de båda klasserna vilka metoder de måste implementera.

Vad är fördelen med att använda interface C jämfört med att klasserna A och B implementerar just de metoder som behövs? De skulle ju likaväl kunna innehålla metoderna Save och Get utan att för den skull implementera ett Interface. Är det för att klasserna så lika varandra som möjligt eller vad? Det är denna sista fråga jag aldrig fått ngn bra förklaring på.

>>Men då är alltså interfacet mer som ett slags kontrakt för de klasser som implementerar interfacet?

100% korrekt

>>Vad är fördelen med att använda interface C jämfört med att klasserna A och B implementerar just de metoder som behövs

arv används när något "är något"

en "bil" är ett "fordon"
en "människa" är ett "däggdjur"

osv.

interfaces används mer i "kan utföra något"

tex en typ som implementerar IComparable, säg tex int32

en int32 "kan jämföras" (med något)

något som implementerar IClonable:

en gnu kan klonas


sedan finns det fall där man använder interfaces mer i samma bemärkelse som arv.
det är väldigt vanligt när man vill kunna plugga in helt nya implementeringar i sitt system.

kärver man att någon måste ärva en basklass , så blir alla implementeringar låsta till att just ärva din basklass..

med ett interface (kontrak) så kan den som skriver implementeringen ärva vad han vill (tex någon av frameworkklasserna , Contextbound etc)

så jag föredrar att koda mina kontrakt som just interfaces , även om jag sedan oxo har en basklass som implementerar det interfacet.

då har jag fördelarna med båda... någon kan skriva en _helt_ ny implementering mot mitt interface.
och vill man bara modda befintligt beteende så kan man ärva o overrida basklassens metoder..

//Roger

Tänker bara lägga till en ren kodmässig (finns ju iofs. andra fördelar med det här) sak som gör ett interface överlägset att "bara" lägga till de rätta metoderna i klassen.

<b>Exempel ett;</b>
Du har ett objekt som du behöver anropa en metod på. Objektet måste ha den här metoden. Om vi använder oss av interface blir det såhär:

IMittInterface mf;
mf = mitt_objekt;
mf.ExekveraFisk();

Om vi inte vill använda interface blir det såhär:

object mf;
mf = mitt_objekt;
mf.GetType().GetMethod("ExekveraFisk").Invoke(s, null); //Kräver lite högre permissions än vad som är normalt för "osäkra" program. Här används alltså reflektion eftersom att det vid kompileringen inte är känt vilken datatyp "mf" är utav

Dessutom blir det knöligt om vi har två metoder som heter likadant men har olika parametrar, då måste vi dessutom fråga efter vilken metod vi vill ha.

En annan fördel är att interfaces kan garantera att alla metoder och egenskaper som behövs verkligen finns, oavsett om någon har glömt något eller om en ny version har kommit ut. Det kan du inte garantera utan interfaces, med interfaces får du fel redan vid kompileringen, utan interfaces får du fel vid körningen istället.

Det är en ganska lång omväg att skippa interfaces :)

det där var inte ett argument för interfaces , det var ett argument för att typa sina params/variabler
du kunde gjort exakt samma sak med en basklass...

(ok , med explicit implementerade ifaces så kan man ha flera metoder med samma signatur per klass.. men detär överkurs ;-) )

<b>det där var inte ett argument för interfaces , det var ett argument för att typa sina params/variabler
du kunde gjort exakt samma sak med en basklass...
</b>

Det var väl ett bra argument för interfaces???

Vad är meningen att ärva dfrån en basklass om man inte skall ha någon funktionalitet i den? I ett fall så vill jag att dynamiskt laddade moduler skall kunna spara det de håller på med, men jag inte vad de gör, eller vad de innehåller, och jag vill inte heller bry mig om det. Skulle jag då ha en basklass så måste den ju se ut som följer

<code>
public class MyClass
{
public void Save()
{
//spara data här....
//här kan vi inte spara data för vi vet inte vad de skall göra.
//Visst kan vi sätta en basfunktionalitet här, mn varför om vi vet att ingen som kommer att
//ärva från basklassen komemr att bry sig om den?
}
}
</code>

och sedan måste alla ärva den och köra en override på metoden.
<code>
public class MyMakeStuffClass : MyClass
{
public override void Save()
{
//spara data här....
}
}
</code>

Saken med interfaces är ju att vi skiter ju i vad de gör, bara de implementerar metoderna vi vill komma åt.

alternativet mot ovan är ju
<code>
public interface IMyInterface
{
void Save();
}

</code>

och
<code>
public class MyMakeStuffClass : IMyInterface
{
public void Save()
{
//spara data här....
}
}
</code>


Arv är bra, men bara när det används för just arv. Dvs använd arv när du vet att det finns något i din basklass som är värt att ärva, finns det absolut inget som är värt att ärva eller man inte behöver bry sig om vad de gör så fungerar interfaces ypperligt.

>>Saken med interfaces är ju att vi skiter ju i vad de gör, bara de implementerar metoderna vi vill komma åt.

vilket är exakt samma sak som gäller för abstrakta metoder i en basklass..

>>Vad är meningen att ärva dfrån en basklass om man inte skall ha någon funktionalitet i den?

var framgick det av oscars exempel att det inte fanns någon basfunktionallitet man inte ville ärva in?

exemplet var ju krystat , att göra gettype().GetMethod(...) för att göra någon form av lateboundanrop är ju bara lämpligt om det inte finns något gemensammt interface för objekten alls.. (klass eller vanligt interface dvs)

> Tänker bara lägga till en ren kodmässig (finns ju iofs. andra fördelar med det här) sak

Observera; jag sa <b>lägga till</b>, jag la till en sak till ditt svar som jag tyckte passade.

> du kunde gjort exakt samma sak med en basklass...

Nej, precis som du skrev ovan; man kanske inte vill tvinga arv från en viss basklass... Vill man inte det och man inte vill använda interfaces så blir det en knölig reflectionhistoria. Det var det jag ville poängtera