Er funksjoner ut?
svend
og tok da opp tema som variabler, beslutninger, løkker, arrays og -
funksjoner. Jeg skal nå revidere kurset, og trenger input fra noen som
faktisk programmerer i VB til daglig. Som lærer har en litt mangel på
praktisk erfaring med tanke på hva som er moderne i dagens samfunn :-)
En funksjon er i tidligere utgaver av kurset forklart som en svart boks
som utfører noe, og returnerer et svar. En funksjon deklareres slik:
Function summer(t1 as Integer, t2 as Integer) as Integer
return t1 + t2
End Function
Den ligger gjerne øverst i koden, og kan kalles opp i for eksempel
Button1_Click. 1 av 12 tema er dedikert til funksjoner. I utgangspunktet
tenkte jeg å kutte ut funksjoner helt, siden funksjoner har en stor
likhet med metoder (eneste forskjell jeg ser, er at funksjonen ikke
lever innenfor noen selvdefinert klasse). Men så ble jeg i tvil:
Leksjonen om funksjoner er god, fordi den forklarer hele poenget med å
generalisere og gjenbruke kode. Jeg tenker at det er lettere å forstå
funksjoner først, og så introdusere OOP, i stedet for først å
introdusere klassebegrepet og så gjøre om eksisterende funksjons-tekst
til å bli metoder.
Til nå har vi gått gjennom:
1-2: variabler
3-5: kontrollstrukturer
6: arrays
Jeg tenker slik foreløpig, men trenger altså input:
7: funksjoner. Hva er en funksjon? Hvordan tenke generalisering av
kode? Argumenter, kalle funksjonen
8: OOP-intro. Hva er en klasse? Egenskaper, metoder. Likheten mellom
metode og funksjon.
9: Mer OOP. Arv etc.
10-12: Bruke innebygde .NET-klasser til å koble til database, litt
filbehandling og ymse.
Spørsmålene mine er dermed:
- Vil du noen gang i praksis bruke funksjoner?
- Er det lettere å forstå grunnleggende OOP når en først har innført
begrepet "funksjon", eller bør en først ta klasser, og i så fall gå rett
på metoder ?
- Er det slik at egendefinerte funksjoner likevel brukes selv om en
programmerer OOP-basert?
- Jeg bruker funksjoner (function) til å returnere en verdi, og
prosedyrer (sub) til å for eksempel vise en meldingsboks. Hva gjør du?
--
Svend A
Per Larsen
Svarer "inline' nedover...
On 16.10.2007 21:00, svend typed the following::
> Hei, jeg underviser i programmering i VB. Kurset ble laget under VB 6,
> og tok da opp tema som variabler, beslutninger, løkker, arrays og -
> funksjoner. Jeg skal nå revidere kurset, og trenger input fra noen som
> faktisk programmerer i VB til daglig. Som lærer har en litt mangel på
> praktisk erfaring med tanke på hva som er moderne i dagens samfunn :-)
Kan ikke akkurat si at jeg programmerer i VB til daglig, men dog rimelig
ofte; VB6 og — til tider — VBA. Begge deler i all hovedsak mot database
(på SQL Server) i jobbsammenheng.
Ja, ofte. Mine funksjoner er vel (i hovedsak) 'plassert' i moduler, og
da oftest også 'public'. Som du sjøl sier lengre opp en en årsak å
gjenbruke kode (enklere vedlikehold av koden), en annen kan jo være å
kunne erstatte en (kanskje både omfattende og komplisert) kodebit i din
kode med et enkelt funksjonskall:
If (MyFunction(x) > 100) Then
'Do Something
...
Else
'Do Somthing Else
...
Endif
Jeg deklarerer alltid parametrene til funksjoner (og Sub's) 'fullt ut',
ditt eksempel ovenfor ville jeg derfor skrevet (med ByVal):
Function summer(ByVal t1 as Integer, ByVal t2 as Integer) as Integer
'// NB: VB6 måten (ikke med 'return'):
summer = t1 + t2
'// Pirk: 'summer' burde muligens være Long for å unngå 'overflow'
End Function
Metoder bruker jeg mot klasser (derunder skjemaer [Forms] og rapporter
[DataReports], og de gjør jo da gjerne noe i forhold til data som
tilhører klassen.
> - Er det lettere å forstå grunnleggende OOP når en først har innført
> begrepet "funksjon", eller bør en først ta klasser, og i så fall gå rett
> på metoder ?
Tror det er bedre å starte med funksjoner (og Sub-ber) dersom du i alle
fall skal gjennomgå dem (og ikke bare — langt uti — nevne dem som en
spesialvariant av metoder og egenskaper [Properties]). Husk at
properties har en 'Get' og en 'Let' (eller 'Set' for objekter) metode,
og dersom du ønsker at noen (interne) data for en klasse skal være 'read
only' for ekstern kode, trenger du bare 'Get' (ev. bare 'Let' for 'write
only' data).
Ettersom properties og methods begge kan benytte (og endre) alle data i
klassen, og gjøre 'de samme tingene', kan det kanskje være tilfeller
hvor det ikke er opplagt om en skal lage en metode eller en 'Property'.
> - Er det slik at egendefinerte funksjoner likevel brukes selv om en
> programmerer OOP-basert?
Ja, se ovenfor. VB6 har jo både interne Functions og Subs. F.eks. finnes
jo MsgBox både som Sub og som Function: Er du interessert i om brukeren
trykket på OK, Avbryt eller noe annet, bruker du funksjonen.
> - Jeg bruker funksjoner (function) til å returnere en verdi, og
> prosedyrer (sub) til å for eksempel vise en meldingsboks. Hva gjør du?
Mine funksjoner returnerer alltid en verdi, er jeg ikke interessert i
verdien (fordi den er irrelevant et [eller annet] sted i koden), bruker
jeg Call:
Call MyFunction(x)
Følgelig bruker jeg ingen Sub for å vise meldingsboks, men en Function,
og 'Call' dersom returen fra funksjonen ikke er relevant.
Det kan vel også legges til at jeg vel hovedsakelig bruker Sub når jeg
ikke ønsker noen verdi i retur, og når kallet neppe kan feile. Dersom
den nå likevel feiler, bør den (i min kode) avsluttes i en 'Err.Raise'
som så koden som kalte den må håndtere.
Til slutt minner jeg på at en funksjon også kan skrives slik at den bare
returnerer 'OK' eller feilkode (ved feil), eller True/False. Mange av
API-kallene i windows (kanskje det blir Kurs 2) er skrevet slik.
--
mvh
PerL
svend
>> Spørsmålene mine er dermed:
>> - Vil du noen gang i praksis bruke funksjoner?
>
> Ja, ofte. Mine funksjoner er vel (i hovedsak) 'plassert' i moduler, og
> da oftest også 'public'. Som du sjøl sier lengre opp en en årsak å
> gjenbruke kode (enklere vedlikehold av koden), en annen kan jo være å
> kunne erstatte en (kanskje både omfattende og komplisert) kodebit i din
> kode med et enkelt funksjonskall:
Takk for mange gode og interessante bemerkninger. Jeg fant på MSDN at
funksjoner fortsatt er i god bruk under .NET 3.0:
You can define Function procedures in modules, classes, and structures.
They are Public by default, which means you can call them from anywhere
in your application. You declare each argument the same as you do for a
Sub procedure.
Kilde: http://msdn2.microsoft.com/en-us/library/6xxtk8kx.aspx
Jeg går for å først introdusere funksjoner, og så forklare OOP.
--
Svend A
gjemmesiden.blogspot.com
Ompa Jompa
>
> You can define Function procedures in modules, classes, and structures.
> They are Public by default, which means you can call them from anywhere
> in your application. You declare each argument the same as you do for a
> Sub procedure.
Det er mao. ikke som du skriver innledningsvis noen forskjell på metoder
(med returverdi) og funksjoner, siden du godt kan definere funksjoner i
klasser (også).
Det du kanskje bør spørre deg selv (og/eller andre) om er hvorfor man i
det heletatt ønsker å definere funksjoner utenfor klasser, slik man kan
i VB. I Java er det ikke mulig å gjøre det.