j000rn Skrevet 7. august 2008 Del Skrevet 7. august 2008 Personlig synes jeg at method overloading i de fleste tilfeller gir et mye renere grensesnitt og utfører akkurat det samme. Enig. Om du absolutt har ørten parametere som skal inn, så hvorfor ikke sende et objekt isteden? Se f.eks. System.Net.SmtpClient.Send(). Du har noen enkle overloads med forskjellige parametere... .og så har du .Send(MailMessage m) hvor du kan spesifisere så mye du vil. Lenke til kommentar
HDSoftware Skrevet 7. august 2008 Forfatter Del Skrevet 7. august 2008 Hadde vi ikke visst om method overloading ville kanskje spørsmålet vårt vært litt annet? Det er mulig, jeg bare påpekte at et av problemene med å bruke nullable verdier er at man legger en føring på bruken av funksjonen. Når du lager en funksjon som tar int? bare fordi den skal ha en defaultverdi krever du at når du skal bruke den funksjoen må du enten bruke int? typen selv, caste til int? eller skrive inn en null som ikke har noen funksjon. Personlig synes jeg at method overloading i de fleste tilfeller gir et mye renere grensesnitt og utfører akkurat det samme. Joda, du har rett i det. Men hvorfor dette ikke er implementert direkte i prototypen vet jeg ikke. Som nevtn tidligere så har Clarion fikset dette enkelt, med enten default verdier eller rett og slett omittable parameter. Det er vel både fordeler og ulemper med dette. Fordelen slik jeg ser det er at man har alt i en prosedyre/metode. Ulempen er nettop det samme, at man faktisk på ta hånd om dette i samme prosedyre. Er vel strengt tatt en vanesak. I Clarion kan man selvsagt gjøre det på samme måte som i C#, ved å ha en metode som kaller en annen fordi et parameter er utelatt, men strengt tatt kunne det vært mulig å prototype dette direkte. Sikkert bare et strategisk valg som blei gjort en gang da C# blei definert. "Problemet" med Nullable parametere er jo at man fortsatt må sende inn en parameter, selv om den er NULL. Det er vel strengt tatt ingen grunn til at ikke kompilatoren kunne godkjent følgende: public void MinFunc(int? pVerdi) {...} MinFunc(); MinFunc(null); Jeg mener jo at begge måter burde vært tillat. Men grunnen er vel at det er bestemt at C# skal være optimalt entydig og derfor er ikek dette akseptert. Bare tipper altså ;-) Lenke til kommentar
Glenn F. Henriksen Skrevet 7. august 2008 Del Skrevet 7. august 2008 (endret) Joda, du har rett i det. Men hvorfor dette ikke er implementert direkte i prototypen vet jeg ikke. ... Det er vel strengt tatt ingen grunn til at ikke kompilatoren kunne godkjent følgende: Ikke før du gjør slik: public void MinFunc(int? pVerdi) {} public void MinFunc(float? pVerdi) {} MinFunc(); // Hvilken metode skal kalles her? MinFunc(null); Ja, søkt eksempel, og ja, jeg ser at man kan synes at default parametere er en kjekk ting, personlig savner jeg de som sagt ikke. C# gjengen har faktisk svart på hvorfor de ikke la det inn. Selv prototyper jeg med å skrive bruken av en metode først og så får jeg VS (eller egentlig R# i mitt tilfelle) til å generere overload metoden for meg. Sammen med intellisense så utgjør det minmalt med ekstraarbeid og gir meg (synes jeg) et enklere grensesnitt og mer fleksibilitet. Endret 7. august 2008 av wallatu Lenke til kommentar
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå