我注意到,使用C#4中的可选参数,如果您在接口上指定了可选参数 ,则 不必在任何实现类上将该参数设为可选:
public interface MyInterface { void TestMethod(bool flag = false); } public class MyClass : MyInterface { public void TestMethod(bool flag) { Console.WriteLine(flag); } }
因此:
var obj = new MyClass(); obj.TestMethod(); // compiler error var obj2 = new MyClass() as MyInterface; obj2.TestMethod(); // prints false
有谁知道为什么可选参数设计成这种方式工作?
一方面,我认为覆盖接口上指定的任何默认值的功能很有用,尽管说实话,我不确定您是否应该甚至可以在接口上指定默认值,因为这应该由实现决定。
另一方面,这种断开连接意味着您不能始终交替使用具体的类和接口。当然,如果在实现上指定了默认值,这将不是问题,但是如果您将具体类公开为接口(例如,使用某些IOC框架注入具体类),那么实际上就没有问题了。具有默认值的点作为调用方,无论如何都必须始终提供它。
更新:这个问题是我2011年5月12日博客的主题。感谢您提出的伟大问题!
假设您有一个描述的接口,以及一百个实现该接口的类。然后,您决定将接口方法之一的参数设为可选。您是否在建议正确的事情是让编译器强迫开发人员查找该接口方法的每个实现,并使参数也可选?
假设我们做到了。现在,假设开发人员没有实现的源代码:
// in metadata: public class B { public void TestMethod(bool b) {} }
// in source code interface MyInterface { void TestMethod(bool b = false); } class D : B, MyInterface {} // Legal because D's base class has a public method // that implements the interface method
D的作者应该如何进行这项工作?在您的世界中,他们是否需要打电话给B的作者,并要求他们为他们提供新版本的B,使该方法具有可选参数?
那不会飞。如果有 两个 人打电话给B的作者,而其中一个人希望默认为true,而其中一个人希望为false,该怎么办?如果B的作者只是拒绝一起玩怎么办?
也许在这种情况下,他们将被要求说:
class D : B, MyInterface { public new void TestMethod(bool b = false) { base.TestMethod(b); } }
拟议的功能似乎给程序员增加了很多不便,而代表能力没有相应增加。此功能的显着优势是什么,可以证明用户增加了成本?
更新:在下面的评论中,supercat提出了一种语言功能,它将真正增加语言的功能并启用某些类似于此问题中描述的场景的方案。仅供参考,该功能- 接口中方法的默认实现-将添加到C#8中。