echoSweMedlem sedan nov. 20041 189 inlägg Hej!
Hade någon kunnat förklara vad interfaces går ut på? Jag har använt dem en del själv, men jag förstår till exepel inte skillnaden mellan ett interface och att ärva en klass eller en abstrakt klass i C#.
Det jag har förstått är att de typ är som kontrakt som den funktioner som ärver dem förbinder sig att uppfylla i form av funktionalitet... Typ IEnumerable
GrynetMedlem sedan maj 2001329 inlägg echoSweMedlem sedan nov. 20041 189 inlägg Ja, den var bra. Den bekräftade lite av det jag trodde.
Vad är skillnaden på en virtual och en abstract class då?
Interfaces - det handlar ingenting om att låta data passera genom "interface-et", utan bara om att kontraktera vissa metoder och egenskaper? Hur skriver man ett interface?
PhorpherMedlem sedan feb. 20002 300 inlägg
echoSwe skrev:
Ja, den var bra. Den bekräftade lite av det jag trodde.
Vad är skillnaden på en virtual och en abstract class då?
Interfaces - det handlar ingenting om att låta data passera genom "interface-et", utan bara om att kontraktera vissa metoder och egenskaper? Hur skriver man ett interface?
Generellt kan man säga om Arv vs. Interfaces:
Använd arv vid "is-a"-relationer
Klassen Bil ärver av basklassen Fordon.
Använd interface vid "can-be"-relationer
Interfacet IComparable specar en CompareTo-metod. Denna funktionalitet är inte bara specifik för t.ex. en Fordon/Bil-klass utan kan användas på alla typer av objekt som ska kunna jämföras (och t.ex. sorteras)
Skillnaden på Abstract och Virtual:
Abstract
En abstrakt metod Foo() i en klass Bar, innehåller ingen implementation. Alla klasser som ärver av Bar måste implementera metoden Foo().
Virtual
Klassen Bar tillhandahåller en metod Foo() med tillhörande implementation, men denna metod kan överlagras (override) i subklasser till Bar för att på så sätt få ett mer specifikt beteende än vad basklassens implementation av Foo() har.
Implementation av Interfaces:
namespace WebForum
{
interface IComparable
{
public bool CompareTo(object obj);
}
}
En klass som implementerar ett interface:
namespace WebForum
{
public class Bar : IComparable
{
... Konstruktor m.m
public bool CompareTo(object obj)
{
// Kod för jämförelse
}
}
}
echoSweMedlem sedan nov. 20041 189 inlägg En aha-upplevelse :). Tack!
Vad är då skillnaden mellan en abstrakt klass och ett interface?
- En klass kan endast ärva en klass en gång till skillnad från ett Interface
- En abstrakt klass ... något med egenskaper?
UlfTMedlem sedan maj 20018 027 inlägg
echoSwe skrev:
- En klass kan endast ärva en klass en gång till skillnad från ett Interface
En del programmeringsspråk tillåter faktiskt multipelt arv, så den skillnaden stämmer inte.
echoSwe skrev:
- En abstrakt klass ... något med egenskaper?
En abstrakt klass kan inte instansieras. Däremot kan andra klasser ärva från den, och de kan i sin tur vara sådana som kan instansieras (om inte de också är abstrakta, förstås).
echoSweMedlem sedan nov. 20041 189 inlägg Aha, så vad de då ärver är den abstrakta klassens metoder och egenskaper förutsatt att de inte också är abstrakta? Så den stora fördelen är att man inte behöver skriva om sina metoder om man använder sig av abstrakta klasser?
(Snackar mest i C#)
...och i praktiken, till exempel när det gäller datalager, n-tier utveckling alltså, hur skulle ni i princip använda dessa olika saker: interface, virtual class, abstract class, delegates?
UlfTMedlem sedan maj 20018 027 inlägg
echoSwe skrev:
Aha, så vad de då ärver är den abstrakta klassens metoder och egenskaper förutsatt att de inte också är abstrakta?
De ärver metoderna och egenskaperna, även om de är abstrakta. Abstrakt betyder enbart att klassen inte kan instansieras.
echoSweMedlem sedan nov. 20041 189 inlägg Ja... Fortsatte på ditt snack i inlägget ovanför. :)
(offtopic: hittade en trevlig kontroll:
http://www.codeproject.com/aspnet/ImageCMS1.asp
http://www.codeproject.com/aspnet/ImageCMS2.asp )
GladhMedlem sedan maj 20012 812 inlägg
En klass som implementerar ett interface:
Kod:
namespace WebForum
{
public class Bar : IComparable
{
... Konstruktor m.m
public bool CompareTo(object obj)
{
// Kod för jämförelse
}
}
}
Om man implementerar interfaces så bör man göra det explicit, alltså man måste gå igenom sitt interface för att komma åt metoden.
namespace WebForum
{
public class Bar : IComparable
{
... Konstruktor m.m
private bool CompareTo(object obj)
{
// Kod för jämförelse
}
bool IComparable.CompareTo(object obj)
{
return CompareTo(obj);
}
}
}
Jobbigt en massa onödig kod är det säkert någon som tycker, men det ger faktiskt en fördel och det är att man kan implementera ett annat interface med metoden CompareTo() och låta detta inteface anropa en annan privat method. Detta kan vara mycket användbart när man implementera ny funktionalitet samtidigt som gammal kod skall kunna köra på det som redan finns och man vill ha samma namn på methoderna.
Samt att du får fördelen att du tvingar användaren att alltid accessa instansen av ditt objekt genom ett interface. Genom att göra så är det enkelt att implementera Factory klasser eftersom du i din kod inte har en referense till någon specifik klass, utan till ett interface, och detta gör det väldigt enkelt att byta ut den klass som du vill instansera.
Ett exempel där vi använder detta flitigt är när man kallar från "Frontend" till "backend" genom en "ServiceAgent" (http://msdn.microsoft.com/practices/apptype/webapps/default.aspx?pull=/library/en-us/dnbda/html/distapp.asp) denna serviceagent kan antingen kalla backend via SOAP eller så kan den ha en instance av backend som en vanlig referense. Det betyder att vi kan antingen anropa vår backend via en webservice på en annan maskin, eller använda en lokal dll som har vår backend, och med hjälp av en factory och configurationsfiler kan vi enkelt skapa vilken vi vill använda och eftersom båda implementerar samma interface så opererar vår frontend mot detta interface och har alltså ingen anning om backend kör på en webservice eller på vår egen maskin.
Hoppas någon förstår, mycket enklara att förklara om man har en tavla att rita på :)
- M