--- title: "Varför undvika optional parametrar?" type: "forum-thread" url: "https://www.webforum.nu/amne/dotnet/158092-varför-undvika-optional-parametrar" topic: ".NET" topic_url: "https://www.webforum.nu/amne/dotnet" author: "Lukaspojken" published: "2007-03-12T13:45:28.000Z" updated: "2007-03-15T07:18:13.000Z" replies: 9 views: 705 page: 1 pages: 1 language: "sv-SE" site: "webForum — webforum.nu" rights: "Upphovsrätten till varje inlägg tillhör dess författare." attribution: "Citera som: webForum, https://www.webforum.nu/amne/dotnet/158092-varför-undvika-optional-parametrar" --- # Varför undvika optional parametrar? ## #1 — Lukaspojken, 2007-03-12T13:45Z I VB.net så kan man använda sig av optional parametrar. Jag vet att det är många som rekommenderar att man inte ska använda dessa. Hur kommer det sig? Permalänk: https://www.webforum.nu/p/158092 ## #2 — emission, 2007-03-12T15:42Z Oj, det finns många anledningar, men den främsta tycker jag är att metoderna inte blir CLS compliant, eftersom endast VB har stöd för optional parameters (de blir ju inte optional i C# t.ex.) Dessutom läggs optional parameter-värdena in vid kompilering, i den assembly som gör anropet. Ponera att du först har optionalvärdet "tapir" i en metod i din huvudassembly, och anropar denna metod från en annan assembly. Några veckor senare inser du att kunden är en vegetarisk restaurang, byter raskt defaultvärdet till "avocado" och skickar din uppgraderade huvudassembly till kunden. Guess what? Inget har ändrats, eftersom värdet "tapir" är inkompilerat i den anropande assemblyn. Been there, done that! Med andra ord, sky dem som pesten! Permalänk: https://www.webforum.nu/p/1944656 ## #3 — erka, 2007-03-13T07:40Z > Några veckor senare inser du att kunden är en vegetarisk restaurang, byter raskt defaultvärdet till "avocado" :i Bästa liknelsen i år Permalänk: https://www.webforum.nu/p/1944828 ## #4 — Lukaspojken, 2007-03-13T15:11Z Det visste jag inte men det var ett riktigt bra argument! Men du ser inga fördelar med optional parametrar där du skulle kunna tänka dig ha använt det om det fanns stöd för det i tex C#? Permalänk: https://www.webforum.nu/p/1944954 ## #5 — OveRRidE, 2007-03-13T15:34Z Optional-parametrar beskriver ju inte vad de olika kombinationerna av angivna/utelämnade parametrar innebär, till skillnad från att använda Overloads där varje uppsättning blir som en ny implementation av metoden, och kan dokumenteras därefter. Man ska nog undvika optionals i alla fall man kan, om man jobbar i .NET-miljö. Permalänk: https://www.webforum.nu/p/1944961 ## #6 — emission, 2007-03-13T15:41Z Nej, jag ser inga fördelar. Optional-parametrar hade definitivt sin plats i VB6, men enda anledningen till att de ha överlevt till VB.NET är för att förenkla konvertering och för att blidka gamla VB6-programmerare. Permalänk: https://www.webforum.nu/p/1944965 ## #7 — Lukaspojken, 2007-03-14T09:27Z Detta med överlagring får mig att minnas en metod jag gjorde för ett tag sedan. Kommer inte riktigt ihåg vilka inparametrarna var men det såg ut något i stil ut med detta: \[kod\] Sub DebugTable(Byval DtaTable AS Datable, Optional Byval SortByColumn AS String = "", Optional ByVal FilterColumns AS String = "", Optional Byval SearchString AS String = "", Optional Byval ShowInGridview AS Boolean = False) \[kod\] Skulle man överlagra alla de möjliga kombinationer man kan använda sig av metoden på så blir det en del. Därför kanske man inte ska göra det i ett sådant fall, eller hur ser ni på det? En annan alternativ lösning skulle kunna vara att instansera ett debugobjekt och därefter sätta eventuella egenskaper på det. Skulle det vara en bättre lösning rent generellt? I detta fallet kanske det inte är det eftersom man använder metoden i "immediate window" så det är lite av ett specialfall. Men vad tycker ni rent generellt? Permalänk: https://www.webforum.nu/p/1947973 ## #8 — Gladh, 2007-03-14T19:27Z Själv är jag kluven i frågan! Visst är det bra att ha alla sina metoder överlagrade bra dokumenterad vad de skall göra osv osv.. Men precis som lukas säger så är det inte så kul att skapa sju överlagrade metoder för att man råkar ha 3 parameters som kan kombineras på olika sätt. Ännu väre blir det om alla 3 parameters råkar vara av samma datatyp, hur skall man då skilja på att om det är: Data(string FirstName, string LastName) Data(string FirstName, string Adress) Detta kommer kompilatorn få frispel på, nej i det lägget så är optional en bättre lösning, eller så får man skapa sina input objekt som kan innehålla de olika datavärden som man behöver, men då har man ju tappat bort den säkerhet och dokumentation som man får med överlagring... jobbigt.... Till och med MS har insett problemet och i många av attributen som MS har skapat så kan man ju använd "Named Parameters" och det är ju en typ av Optional parameters... \- M Permalänk: https://www.webforum.nu/p/1948111 ## #9 — emission, 2007-03-14T21:33Z Själva konstrukten är det inget fel på, men implementeringen suger. I DebugTable-fallet ovan tycker jag inte att det är något problem. Nulla de parametrar som du inte vill sätta och låt metoden avgöra vad som är ett bra defaultvärde. Permalänk: https://www.webforum.nu/p/1948166 ## #10 — Gladh, 2007-03-15T07:18Z > **emission skrev:** > > Nulla de parametrar som du inte vill sätta och låt metoden avgöra vad som är ett bra defaultvärde. Visst så kan man göra, men det är ju inte speciellt snyggt!!!! Sedan... hur nullar du en boolean ;) (ja ja vet...., men det är faktiskt ingen boolean då...) \- M Permalänk: https://www.webforum.nu/p/1948180 --- Tråden på webben: https://www.webforum.nu/amne/dotnet/158092-varför-undvika-optional-parametrar