Gå til innhold

Anbefalte innlegg

Hei, etter å ha lest deler C# Bible sitter jeg igjen med noen spørsmål:

 

1: Hva kan en struct gjøre som en klasse ikke kan? i boka virker det som en klasse kan brukes til alt en struct kan, og i tillegg har structs enkelte begrensninger (min 1 constructor parameter f.eks.)

 

2: Hvilken praktisk nytte har enumerations?

 

3: Hva trenger en egentlig interfaces til? og hva er forskjellen på et interface og en abstract base class?

Lenke til kommentar
Videoannonse
Annonse

En klasse kan det samme som en struct, men en struct har visse begrensninger. Jeg stilte selv det samme spørsmålet i C++. Structs henger litt igjen fra før klasser kom inn i bildet. Jeg ser ikke den helt store fordelen i å bruke de.

 

enums er praktiske for å holde litt mer oversikt i koden din. Egentlig vil jo disse ha verdien 0,1,2... Men det gjør koden litt lettere lesbar, så slipper du å sitte og huske på "0 det var xxxxx, 1 betyr xxx" med tanke på hvis du lager en funksjon som skal behandle data ut ifra diverse kriterier sendt inn som argumenter til funksjonen. (u c?)

 

punkt 3 må du se på noen andre for å få en forklaring på :p

Lenke til kommentar

En vesentlig forskjell mellom en struct og en class i C# er at en struct er en ValueType mens en class ikke er det:

 

MyStruct s1 = ...;
MyStruct s2 = s1;

MyClass c1 = ...;
MyClass c2 = c1;

 

Forskjellen her er at struct'ene s1 og s2 er like, men peker ikke på samme struktur i minnet, mens klassene c1 og c2 peker på samme struktur i minnet.

 

Eksempler på structs er f.eks. Int32, Point og Color.

 

Det finnes plenty med fordeler med å bruke structs, siden struct og class lever side om side. Tenk litt på hvordan man bruker f.eks. Int32 så skjønner du det bedre.

 

Øyvind

Lenke til kommentar
  • 2 uker senere...

Structs kan er et value objekt, dvs. at de blir kopiert når du setter

struct a = b; så vil b være en kopi av a

klasser er alltid en referanse, med mindre du bruke IClonable og implementerer object.Clone() men det er veldig mye jobb :p

 

I C++ er det ingen forskjell på struct og class, bortsett fra at felt i structs er public som default, private som default i klasser.

 

Enumerations er veldig nyttig til bitfelt:

public enum anewenum : uint
{
 bit1 = 1
 bit2 = 2
 bit3 = 4
}

anewenum b;
b = anewenum.bit1 | anewenum.bit3;
if((b & anewenum.bit1) == anewenum.bit1)
 // bit1 er satt

 

interfaces er veldig nødvendig, et interface garaneterer at en klasse har implementert funksjoner eller egenskaper, så f.eks

interface IMovable { void move(int x, int y); };
interface ISizable { void size(int width, int height); };

class aclass : IMovable { void move(int x, int y) {} };

aclass a;

IMovable b =  (IMovable)a;

 

veldig nyttig når du sitter med en array med forskjellige objekter med forskjellig funksjonalitet.

Lenke til kommentar
  • 4 uker senere...

enum er feks praktisk til konstante verdier som det skal sjekkes mot

 

public enum Kjønn {

Ukjent,

Mann,

Kvinne

}

 

public class Person {

public string Navn;

 

public Kjønn Kjønn;

 

}

 

 

i bruk:

 

Person person = new Person();

person.Navn = "Ola Normann";

person.Kjønn = Kjønn.Mann;

 

//---

 

 

//hvis det er en mann skal det gjøres noe

 

if (person.Kjønn == Kjønn.Mann) {

//det er en mann, og man slipper å bruke kryptiske konstantverdier

}

 

 

 

man vil også få hjelp av Intellisense i visual studio med hvilke verdier som er gyldige for den type.

Endret av woid
Lenke til kommentar

flott, da har jeg hvertfall fått gode svar på det med enumerations og classes/structs.

 

Jeg ser fortsatt ingen praktisk nytteverdi i interfaces? Javel, du kan garantere at en klasse som støtter et interface implementerer funksjonalitet, men hva er poenget? Jeg forstår hva det er og hvordan man bruker det i praksis, men ikke hvorfor. Kan noen komme med et kodeeksempel der det faktisk er nyttig (og helst nødvendig)?

Lenke til kommentar
flott, da har jeg hvertfall fått gode svar på det med enumerations og classes/structs.

 

Jeg ser fortsatt ingen praktisk nytteverdi i interfaces? Javel, du kan garantere at en klasse som støtter et interface implementerer funksjonalitet, men hva er poenget? Jeg forstår hva det er og hvordan man bruker det i praksis, men ikke hvorfor. Kan noen komme med et kodeeksempel der det faktisk er nyttig (og helst nødvendig)?

6403191[/snapback]

Interfacer - grensesnitt på norgisk - er nyttige for så mangt.

Det er en kontrakt mellom to parter; den som implementerer interfacet og den som bruker det. Og som kontrakter flest, når de er publisert kan de ikke endres. I praksis: om du ikke kan reise deg og si "ISomething er endret!" slik at alle brukere hører det, må du lage en ny versjon - ISomething2.

Du må ha brukt dem en stund før det plutselig går opp et aha! og du virkelig blir en Enlightened. Unnskyld, l337.

Noen scenarier hvor intefacer er nyttige:

Du har ikke kontroll over brukere av løsningen din. "Jeg vet ikke noe som helst om objektene dine, men om du gir meg et objekt som implementerer ISomething så kan jeg gjøre noe med det" I .net brukes dette veldig mange plasser - blant annet for serialisering, sortering ("om objektene dine implementerer ISort, kan jeg sammenligne dem mot hverandre og sortere dem")

I web services (og SOA) er det helt essensielt. Selv om det ikke alltid kalles interface, så eksponeres en samling metoder mot omverdenen uten at noen trenger å vite hvordan ting er implementert på serveren.

Så her har vi en decoupling mellom hva du sier at noe gjør, og hvordan det faktisk gjøres. Dette kan være veldig nyttig i teamutvikling; bli enig om et interface - så kan en programmerer lage implementasjonen av interfacet mens de andre kan programmerer mot det før det finnes.

Noen (få) plasser i .net blir det også brukt "marker interfaces". Dette er interfaces som ikke inneholder noen metoder(!), men som allikevel gir mening; den sier noe ekstra om objektet. Se Wikipediawikipedia om du er interessert. I Java er dette mye vanligere, men i .net brukes attributter oftere.

 

En sammenligning? DVI-kontakten til skjermen din bryr seg ikke om den kobles til en PC eller en Mac; så lenge både skjerm og maskin opprettholder sin del av kontrakten fungerer alt ypperlig.

 

- grå -

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...