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!
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#?
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ö.
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.
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?
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:
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...
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.
