data strukturer vs klasser

[HDSoftware]

Heisan

 

Er det mulig å lage en datastruktur?

 

Kan i Clarion gjøre noe slik:

 

Person       GROUP
Navn           STRING(40)
Adresse        STRING(40)
Postnr         STRING(4)
Poststed       STRING(40)
Telefon        STRING(20)
             END!GROUP

 

Dermed kan jeg akksessere denne slik:

Person.Navn = "Ole Morten"
Person.Adresse = "Gata 10"
etc.
etc.

 

Noe tilsvarende i VB2005 ?

 

Ole

[Harald Staff]

Massevis, dette er selve måten å programmere objektorientert.

 

I sin aller enkleste form, sett inn en Class, den får defaultnavn Class1. I den skriver du

 

Public Navn As String

Public Adresse As String

 

Så kan du gjøre f.eks. dette hvorsomhelstfra:

 

Dim Nyperson As Class1

Nyperson = New Class1

Nyperson.Navn = "Jesper"

MsgBox(Nyperson.Navn)

Nyperson = Nothing

 

HTH. Beste hilsen Harald

[Jaffe]

I VB 6.0 kan man i alle fall bruke Type:

 

Type Person
Navn as string
Age as integer
End Type

 

Og deretter dimensjonere noe som "Person", og aksessere feltene:

 

Dim NyPerson as Person

Person.Navn = "Jan"
Person.Age = 31

 

Men jeg vet ikke om det fortsatt er slik i VB2005.

Endret 13. oktober 2006 av Jaffe

[Harald Staff]

Det er sant. Men fordelen med å gjøre det i klasser istedetfor typer (også i VB6) er at man kan skrive ikke bare properties (Navn, Alder, ...) men også methods (Husk meg, Slett meg, Mail meg, ... ) med kode a la

 

Public Sub HuskMeg()

'databasekode her

End Sub

 

i klassemodulen, og så f.eks. lagre så enkelt som:

 

NyPerson.HuskMeg

 

Beste hilsen Harald

[HDSoftware]

Det er sant. Men fordelen med å gjøre det i klasser istedetfor typer (også i VB6) er at man kan skrive ikke bare properties (Navn, Alder, ...) men også methods (Husk meg, Slett meg, Mail meg, ... ) med kode a la

 

Public Sub HuskMeg()

'databasekode her

End Sub

 

i klassemodulen, og så f.eks. lagre så enkelt som:

 

NyPerson.HuskMeg

 

Beste hilsen Harald

7061262[/snapback]

 

Heisan. Jeg viste om dette (ref emne). Tenkte kansje en struktur var mere effektiv enn en klasse. Instansiering av en klasse krever jo tross alt en del mer for prosessoren å håndtere og i dette tilfelle trenger jeg kunn denne daatastrukturen. Det er riktig som Jaffe sier. Det å lage en Datatype er det jeg er ute etter.

 

 

Men jada, begge delene gjør jo samme nytten.

 

 

Takker iallefall for svar ;-)

 

Ole

[HDSoftware]

I VB 6.0 kan man i alle fall bruke Type:

 

Type Person
Navn as string
Age as integer
End Type

 

Og deretter dimensjonere noe som "Person", og aksessere feltene:

 

Dim NyPerson as Person

Person.Navn = "Jan"
Person.Age = 31

 

Men jeg vet ikke om det fortsatt er slik i VB2005.

7061146[/snapback]

 

Ser ikke ut til at dette er støttet lenger :-(

 

Klasse får være løsningen. Er jo nesten det samme

 

Ole

[aadnk]

Ser ikke ut til at dette er støttet lenger :-(

7061941[/snapback]

UDT er riktignok ikke støttet, men dersom en behøver en liknende funksjonalitet, kan en også benytte strukturer:

Private Structure Person

    Dim Name As String

    Dim Age As Integer

End Structure

Nå kan disse, som vanlige klasser, også inneholder metoder - følgelig er det ikke snakk om reelle UDT-typer som i VB6. Strukterer er mer en mindre omfattende utgave av klasser, om du vil, og skal brukes når en ikke forventer å lagre meget informasjon i lang tid.

 

I VB6 er UDT-klasser utvilsomt raskere, især når de skal deinitialiseres, men en hybridløsning kan ofte være det klokeste. Eksempelvis benyttet jeg i ChatLogs både klasser og UDT-arrays for å lagre all informasjonen om chatteloggene. Alle tekstmeldinger ble lagret i ulike arrays i hver sesjon, mens alt annet metadata ble lagret i klasser.

[Harald Staff]

Heisan.  Jeg viste om dette (ref emne).  Tenkte kansje en struktur var mere effektiv enn en klasse. 

Det er vel sant ja. Du spør grunnleggende og sinnssykt avansert om hverandre, så det er vrient å gjette nivået ditt

Jeg bruker konsekvent klasser og samler dem i collections. Det er kraftkrevende, men lynkjapt, effektivt og lett å bygge videre på. Minne og prosessorhastighet er ingen utgift i våre dager, mens programmering og vedlikehold er dyrt. Sier ikke man skal sløse og somle, for all del, men 10% bedre ytelse er bare helt umerkelig nå for tiden ...

 

Beste hilsen Harald

[GeirGrusom]

Har merket at strukturer ganske enkelt blir hentet av GC når en passer de fra funksjoner, så ofte kan resultatet blir blankt hvis du bruker strukturer.

 

Du kan fortsatt lage strukturer som ligner på Visual Basic sin Type

Public Structure Person
 Public Navn As String
 Public Alder As Integer
 Public Sub New(Navn As String, Alder As Integer)
   Me.Navn = Navn
   Me.Alder = Alder
 End Sub
End Structure

Dim per As Person = new Person("Per", 23)
Dim pål As Person
pål.Navn = "Pål"
pål.Alder = 27

Også med VBFixedStringAttribute kan du få til det samme som

Type Person
 Navn As String * 32
 Alder As Long
End Type

 

ved å skrive:

Public Structure Person
 <VBFixedString(32)>Public Navn As String
 Public Alder As Long
End Structure

 

Denne bruker da en attribut til egenskapen Navn.

Attributer kan brukes til mye rart

[HDSoftware]

Det er vel sant ja. Du spør grunnleggende og sinnssykt avansert om hverandre, så det er vrient å gjette nivået ditt 

 

Tja, har jo levd av programvare utvikling i snart 20 år så noe bør en vel ha fått med seg. Basic derimot har jeg ikke brukt siden guttedagene, det vil si QBasic, GWBasic og for ikke å glemme Commodore64, Oric1 og Sinclair Spectrum og ZX-81. Derfor vil du nok se en del grunnleggende spørsmål fra meg i begynnelsen her.

 

Synes forresten jeg har lært utrolig mye de 14 dagene jeg har vert her. Dere er flinke.

 

 

Ole

[HDSoftware]

Har merket at strukturer ganske enkelt blir hentet av GC når en passer de fra funksjoner, så ofte kan resultatet blir blankt hvis du bruker strukturer.

 

Dette ser bra ut. Den NEW greia går igjen ser jeg. En her nevnte vel at dette var en konstruktør. Finens det en tilsvarende Destruktør?

 

Ole

[aadnk]

Finens det en tilsvarende Destruktør?

7074759[/snapback]

Tja, det burde gå å bruke Nothing-nøkkelordet:

oObject = Nothing

[HDSoftware]

Finens det en tilsvarende Destruktør?

7074759[/snapback]

Tja, det burde gå å bruke Nothing-nøkkelordet:

oObject = Nothing

7075133[/snapback]

Neppe

En destruktør er en metode som utfører kode idet objektet destrueres. Her har du et Clarion'sk eksempel:

 

MyClass     Class,Type    'Dette er klasse prototypen
MyProperty    Long
Construct     PROCEDURE   'Konstruktør metoden
Destruct      PROCEDURE   'Destruktør metoden
            END
OneObject   &MyClass      'En referanse til instans av klassen
'-------------------------------------------------------
MyClass.Construct          Procedure
 CODE
 Self.MyProperty = 10
 Message("MyProperty = " & Self.MyProperty)
'-------------------------------------------------------
MyClass.Destruct           Procedure
 CODE
 Message("MyProperty = " & Self.MyProperty)
'-------------------------------------------------------
'--< Hovedprosedyrens kode >-------------------
 CODE
 OneObject &= new(MyClass)  ' I VB er dette slilk: DIM OneObject as new MyClass
 Message("OneObject.MyProperty = " & OneObject.MyProperty)
 OneObject.MyProperty = 20
 Dispose(MyObject)  

Clarion er litt annerledes en VB. Koden må ligge i en eget CODE seksjon. Koden til selve programmet er den nederste CODE seksjonen og det er den som kjøres. De andre CODE seksjonene er kode biten til metodene i klassen. Som du ser er det kunn ETT kall til MESSAGE i selve koden til prosedyren. Alikevel vil det bli vist TRE messages. Den første vil faktisk bli vist allerede i den første linjen i hovedkoden:

OneObject &= new(MyClass)

den neste vises fordi den faktisk kalles i koden, og den siste vil bli vist fordi vi destruerer objektet:

DISPOSE(MyObject)

 

Dette er det jeg mener med en konstruktør og destruktør. Det er viktig å kunne legge inn slike egenskaper til klassen som rydder opp, lukker ting etc. etc.

 

 

Derfor - er det noe tilsvarende i VB?

 

 

Ole

[aadnk]

Derfor - er det noe tilsvarende i VB?

Ah, vel, i så fall må jeg bare beklage. Er ikke så kjent på akkurat den terminologien.

 

I VB6 benytter man metoden Class_Terminate for å håndtere hendelsen som eksekveres når et objekt destrueres. Dette skjer når det er ingen flere referanser til objektet. I .NET kan en enten benytte Finalize() (som kan (men ikke nødvendigvis) kalles av GC når applikasjonen termineres), eller/og (helst begge) implementere IDisposable. Dersom du simpelthen skriver Implements IDisposable i en klasse og trykker ENTER, vil du, i Visual Studio 2005, automatisk få opp standardkoden:

 

Public Class Test

 

    Implements IDisposable

 

    Private disposedValue As Boolean = False        ' To detect redundant calls

 

    ' IDisposable

    Protected Overridable Sub Dispose(ByVal disposing As Boolean)

        If Not Me.disposedValue Then

            If disposing Then

                ' TODO: free unmanaged resources when explicitly called

            End If

 

            ' TODO: free shared unmanaged resources

        End If

        Me.disposedValue = True

    End Sub

 

#Region " IDisposable Support "

    ' This code added by Visual Basic to correctly implement the disposable pattern.

    Public Sub Dispose() Implements IDisposable.Dispose

        ' Do not change this code.  Put cleanup code in Dispose(ByVal disposing As Boolean) above.

        Dispose(True)

        GC.SuppressFinalize(Me)

    End Sub

 

    Protected Overrides Sub Finalize()

        ' Do not change this code. Put cleanup code in Dispose(ByVal disposing As Boolean) above.

        Dispose(False)

        MyBase.Finalize()

    End Sub

#End Region

 

End Class

 

For å kalle Dispose, gjør du noenlunde det samme som i Clarion:

Test.Dispose()

 

Dette er nok den beste måten å uinitialisere klasser som benytter unmanaged ressurser.

[HDSoftware]

For å kalle Dispose, gjør du noenlunde det samme som i Clarion:

Test.Dispose()

 

 

Hmmm. Nettop. Dette er nok måten å gjøre det på.

Hadde håpet det fantes en automatisk greie her fordi man fort kan få problemer uten. Tenk deg at du har et stort klassebibliotek som du benytter i mange programmer. Tenk deg at du plutserlig implementerer denne DISPOSE greia. Da må du inn i alle appene, alle formene, modulene, klassene etc. etc. som bruker disse og vedlikeholde. Ikke bra. Hadde man hatt en slik DESTRUCT metode så hadde alt vert ok fordi den hadde sørget for dette automatisk. CONSTRUCT og DESTRUCT er i Clarion ferdig definerte metoder og kan ikke ha andre navn. De kan heller ikke ta imot parametere og returnerer heller ingen. Når man prototyper disse så er de pr. def VIRTUELLE og vil enten man vill eller ikke kalle opp på Parent nivå for å sørge for at alle arvede klasser også utfører DISPOSE. Dette medfører at man kan lage klasser som er vantette mot minnelekasje etc.

 

Men er det ikke dette i VB så er det ikke.

 

Takker uansett for hjelpen.

 

Ole

[GeirGrusom]

IDisposable er laget for å garantere at en klasse som bruker unmanaged minne skal kunne deallokere dette, og er vanligvis ikke nødvendig å implementere, hvis ikke du bruker mye System.Runtime.Marshal funksjoner.

 

Destructors er ikke garantert å bli kalt

(Kalles disse fortsatt object.Finalize i VB.NET?)

f.eks. hvis noen kaller GC.SuppressFinalize()

 

 

Stort sett er det bare å skrive [object] = Nothing, og hvis du vil slette all informasjon om objektet med engang, kaller du GC.Collect()

Endret 15. oktober 2006 av GeirGrusom

[HDSoftware]

IDisposable er laget for å garantere at en klasse som bruker unmanaged minne skal kunne deallokere dette, og er vanligvis ikke nødvendig å implementere, hvis ikke du bruker mye System.Runtime.Marshal funksjoner.

 

Destructors er ikke garantert å bli kalt

(Kalles disse fortsatt object.Finalize i VB.NET?)

f.eks. hvis noen kaller GC.SuppressFinalize()

 

 

Stort sett er det bare å skrive [object] = Nothing, og hvis du vil slette all informasjon om objektet med engang, kaller du GC.Collect()

7076626[/snapback]

 

 

AHH!! Så det betyr at hvis man lager en Service eller lignende som skal gå og gå så er GC:Collect() ultraviktig. I de fleste andre tilfeller spiller det ingen rolle siden GC håndterer dette ved program terminering. Genialt, enkelt, men viktig å huske på når man terminerer objekter som kunn lever en kort tid.

 

Ole