Gå til innhold

VB, OOP og standardisering [løst]


Anbefalte innlegg

Heisan VB guruer (eller Visual studio om du vil)

 

Jeg har lagt merke til et par ting i Microsoft OOP verden og det er måten man helt uten videre kan bruke metoder i andre klasser direkte. Tenker spesiellt på .Tostring metoden. Det virker som om denne metoden er tilgjengelig uansett klasse og objekt - ja selv i mine klasser der ToString på ingen måte er deklarert, kan jeg bruke den.

 

Noen som kan fortelle meg hvordan dette gjøres? Eller er dette bare en del av VB? For jeg kunne virkelig tenke meg å lage mine egne varianter her.

 

mvh

Ole

Endret av HDSoftware
Lenke til kommentar
Videoannonse
Annonse

Dette fungerer som et tre, alle klasser som inheriter fra object (absolutt alle klasser) har en ToString() funksjon, en GetHash() funksjon og GetType().

Disse vil alltid være med klassen din, i motsetning til GetType() er ToString og GetHash() virtuelle funksjoner, de kan byttes ut i din nye klasse, hvis du ikke sier noe spesielt, hvil den bruke ToString() funksjonen fra forrige gang den var deklarert i treet (hvis du lager Class MyClass så vil den automatisk inherite fra Object, og det er her den får ToString() fra)

Lenke til kommentar
Denne posten burde vel helst vært under .net underforumet hvis jeg ikke tar feil? Det er vel et vb.net spørsmål?

7924687[/snapback]

 

På ingen måte (tror jeg) Det er nermest et spørsmål om OOP og har vel ingenting med .NET å gjøre. Det er selvsagt mulig jeg tar litt feil her hvis det er slik at det er .NET engine som tar seg av dette, men i utgangspunktet er det et generellt OOP spørsmål.

 

Ole

Lenke til kommentar

Jorn79 og GeirGrusom:

 

Skjønner. Det er med andre ord en automatisk prototype dette her, som faktisk gjøres på compiler nivå og ikke byCode. Da hadde sikkert han som kommenterte det litt rett med tanke på at dette er en .NET sak. Jeg går ut ifra at jeg kan gjøre "nesten" det samme med interface? Jeg har gjort mye interfacing i Clarion, men ikke i VB (enda). Må derfor spørre:

 

I Clarion er det slik at et Interface kunn er et tillegs prototype av metoder som er en "felles" platform til klassene. F.eks:

EttInterface       Interface
Init                      PROCEDURE
Kill                       PROCEDURE
                       END

Når jeg skal bruke dette i en klasse gjør jeg slik:

EnKlasse         CLASS,INTERFACE(EttInterface)
EttInterface.Init      PROCEDURE
EttInterface.Kill       PROCEDURE
                      END

 

Og videre kan jeg selvsagt legge egen kode bak disse "interface" metodene. Med andre ord er det ikke noe kode bak interface metodene fra før. Ei heller kan et interface ha properties. BLir det på samme måten i VB tro?

Greia er at bruk av interface gjør at forskjellige klasser med enkelhet kan komunisere med hverandre uten at de egentlig vet om hverandre. Jeg pleier gjøre dette gjennom en kø av objekter, så å si en kø med referanser til komponenter, der objektet i seg selv kaller ut av seg selv og inn i "ukjente" objekter gjennom interfacet. Ganske fancy teknikk egentlig. Det var vel egentlig noe slikt jeg tenkte denne ToString greia var bygget opp rundt.

 

Ole

Lenke til kommentar

Interface fungerer helt likt i .NET som det gjør i Clarion.

Interfaces garanterer at en klasse implementerer visse funksjoner og egenskaper, uten å inneholde noe kode.

En klasse kan inherite fra kun én annen klasse, men så mange interfaces man vil.

Alle funksjoner or egenskaper vil følge med arve-treet, også interfaces.

 

I .NET blir alle klasser basert på Object, enten du liker det eller ikke, derfor er et interface helt unødvendig, siden alle klasser implementerer disse funksjonene uansett.

Endret av GeirGrusom
Lenke til kommentar
I .NET blir alle klasser basert på Object, enten du liker det eller ikke, derfor er et interface helt unødvendig, siden alle klasser implementerer disse funksjonene uansett.

7928181[/snapback]

 

Dette var litt uklart for meg. Du sier alle klassert er basert på objekter?!?! Virker på meg motsatt av all logikk da objecter normalt instanseres fra en klasse. Kan du utdype litt nærmere?

 

mvh

Ole

Lenke til kommentar
Dette var litt uklart for meg. Du sier alle klassert er basert på objekter?!?!  Virker på meg motsatt av all logikk da objecter normalt instanseres fra en klasse.  Kan du utdype litt nærmere?

7930491[/snapback]

 

 

System.Object (ikke "objekter") er en klasse. Alle klasser arver av denne :)

Lenke til kommentar
Dette var litt uklart for meg. Du sier alle klassert er basert på objekter?!?!  Virker på meg motsatt av all logikk da objecter normalt instanseres fra en klasse.  Kan du utdype litt nærmere?

7930491[/snapback]

 

 

System.Object (ikke "objekter") er en klasse. Alle klasser arver av denne :)

7930716[/snapback]

Ahh, da skjønner jeg, men hvorfor gjør dette et interface unødvendig? Hvis jeg ønsker å standardisere mine klasser så er vel et interface den eneste veien, er det ikke? Eller mener du å si at alle objekter i andre grener av dette treet også er tilgjengelig fra mine klasser? I så fall betyr vel dette at alle objekter er globalt definert. Og i så fall, hvordan er det med instanser som går på andre tråder? Jeg er vant til at man kan ha en peker i en prosedyre som er en referanse til et object, f.eks. i en helt annen tråd. Dermed kan man utføre metodene som dette objektet har.

 

Jeg har litt vondt for å forstå trådhåndteringen i VB, men det blir vel klarere etter hvert tenker jeg :-D

 

Ole

Lenke til kommentar

Interfaces er ikke unødvendig i det hele tatt, poenget er egentlig bare at Object ikke er et interface, siden alle klasser arver denne, så vil alle klasser ha disse egenskapene uansett - dette gjelder object, siden det er grunnklassen.

 

Jeg tror ikke .NET er noe annerledes en i Clarion på dette området.

Når det gjelder tråder, så finnes det to begrensinger:

System.Windows.Forms objekter hvor du skal kalle metoder på tvers av tråder, må du bruke Invoke funksjonen.

Når det gjelder alle andre klasser, må variabler som brukes på tvers av tråder deklareres volatile (i C#, jeg vet ikke hva dette heter i Visual Basic)

grunnen til dette, er at variabler som ligger på stack(hver sin stack på hver thread), vil bli lagret i cachen til prosessoren, dette gjør at verdier ikke vil bli ordentlig oppdatert for hver tråd(den gamle verdien, eller null vil ligge der)

volatile hindrer dette.

 

Det tror jeg er det eneste, utenom det er cross-thread call ganske simpelt.

Lenke til kommentar
Når det gjelder tråder, så finnes det to begrensinger:

System.Windows.Forms objekter hvor du skal kalle metoder på tvers av tråder, må du bruke Invoke funksjonen.

7934962[/snapback]

 

Eller man kan være sløv og bare sette:

Control.CheckForIllegalCrossThreadCalls = false;

 

:cool:

Lenke til kommentar
Din late slask!

Således trodde jeg da ikke om dem!

7936850[/snapback]

 

Takker folkens

 

Masse nyttig informasjon her. Har prøvd meg litt på Raiseevent og ser at INVOKE brukes der. Må studere invoke litt mer, men ser bruksmåten. I Clarion måtte jeg gjøre det litt annerledes for å få tak i metoder i andre tråder. Den ene måten jeg kunne bruke var enkelt og greit å overføre adressen til objektet i det jeg startet en ny tråd. I Clarion kan man nemlig starte en tråd med tre parametere og disse måtte være string. Gjorde noe slik:

 

Hovedproc        PROCEDURE
LOC:NewThread      LONG
EttObjekt          &KlasseDef
  CODE
  EttObject &= new(KlasseDef)
  EttObjekt.Verdi1 = 10
  LOC:NewThread = Start(Prosedyrenavn, Format(Address(EttObjekt,@P##########P))

Da vil prosedyren som starter tråden ha tråd ID til den nye tråden

 

Den startede prossedyren vil da se noe slik ut:

Prosedyrenavn       PROCEDURE(pPassedAddress STRING)
ObjektRef             &Klassedef
 CODE
 ObjektRef &= int(pPassedAddress)
 Message(ObjektRef.Verdi1)   ! Vil vise verdien 10
 ObjektRef.Verdi1 = 20          

Siste linje vil sette ny verdi for Verdi1 og den er dermed automatisk tilgjengelig for hovedprosedyren.

 

Går vel ut ifra at dette gjøres på noe av den samme måten i VB.

 

Det som kan være problemet med denne teknikken er jo at to eller flere tråder kan finne på å skrive til verdier i samme objekt samtidig og skape kaos, men dette fikses gjerne med IMUTEX eller Critical Section. Vet ikke om VB har noe slikt, men det går jeg vel ut ifra

 

Ole

Lenke til kommentar
Det stemmer.

se på Mutex klassen.

System.Threading.Thread er klassen for å lagwe nye threads

7939734[/snapback]

Takker

 

Anser problemstillingen som løst. Er det et sted jeg kan "stenge" tråden?

 

Ole

7940390[/snapback]

 

Hvorfor skal du stenge tråden? Det kan hende at andre har kommentarer også...

 

Vanlig er heller å legge til "LØST" eller lignende først i emnetittelen.

Lenke til kommentar
Hvorfor skal du stenge tråden?  Det kan hende at andre har kommentarer også...

 

Vanlig er heller å legge til "LØST" eller lignende først i emnetittelen.

7940452[/snapback]

 

Du - det var vel egentlig det jeg ville ;-)

Stenging av tråd overlater jeg til moderator gutta. Tenkte kansje det var en avkryssing ett eller annet sted der tråden ble merket som LØST eller noe slikt. Fikk dermed svar på spørsmålet ;-)

 

Ole

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...