I noticed that with the optional parameters in C# 4 if you specify an optional parameter on an interface you don,t have to make that parameter optional on any implementing class:
public interface MyInterface
{
void TestMethod(bool flag = false);
}
public class MyClass : MyInterface
{
public void TestMethod(bool flag)
{
Console.WriteLine(flag);
}
}
and therefore:
var obj = new MyClass();
obj.TestMethod(); // compiler error
var obj2 = new MyClass() as MyInterface;
obj2.TestMethod(); // prints false
Does anyone know why optional parameters are designed to work this way?
On one hand I suppose the ability to override any default values specified on the interfaces is useful though to be honest I'm not sure if you should even be able to specify default values on the interface as that should be an implementation decision.
On the other hand, this disconnect means you can't always use the concrete class and the interface interchangeably. This of course, wouldn't be a problem if the default value is specified on the implementation, but then if you're exposing your concrete class as the interface (using some IOC framework to inject the concrete class for instance) then really there's no point having the default value as the caller will have to always provide it anyway.
This question is related to
c#
.net
c#-4.0
interface
optional-parameters
An optional parameter is just tagged with an attribute. This attribute tells the compiler to insert the default value for that parameter at the call-site.
The call obj2.TestMethod();
is replaced by obj2.TestMethod(false);
when the C# code gets compiled to IL, and not at JIT-time.
So in a way it's always the caller providing the default value with optional parameters. This also has consequences on binary versioning: If you change the default value but don't recompile the calling code it will continue to use the old default value.
On the other hand, this disconnect means you can't always use the concrete class and the interface interchangeably.
You already can't do that if the interface method was implemented explicitly.
Just want to add my take here, as the other answers do provide reasonable explanations, but not ones that fully satisfy me.
Optional parameters are syntactic sugar for compile-time injection of the default value at the call site. This doesn't have anything to do with interfaces/implementations, and it can be seen as purely a side-effect of methods with optional parameters. So, when you call the method,
public void TestMethod(bool value = false) { /*...*/ }
like SomeClass.TestMethod()
, it is actually SomeClass.TestMethod(false)
. If you call this method on an interface, from static type-checking, the method signature has the optional parameter. If you call this method on a deriving class's instance that doesn't have the optional parameter, from static type-checking, the method signature does not have the optional parameter, and must be called with full arguments.
Due to how optional parameters are implemented, this is the natural design result.
Optional parameters are kind of like a macro substitution from what I understand. They are not really optional from the method's point of view. An artifact of that is the behavior you see where you get different results if you cast to an interface.
Because default parameters are resolved at compile time, not runtime. So the default values does not belong to the object being called, but to the reference type that it is being called through.
Source: Stackoverflow.com