2011-01-26 95 views
16

我今天的问题:在接口坏的重载方法?你知道,“如果你不在乎省略参数,我们会找出默认值”一种重载方法。 就像是:重载的方法在接口

void Add(object item); 
void Add(object item, bool shouldDoSomething); 
void Add(object item, bool shouldDoSomething, IUltraObscureDeviceContext context); 

在这种情况下,我倾向于认为只有后者属于接口和其他应当在它之上的抽象类来实现。但是再次,我不确定。另外,有些时候你只是希望不同的重载做稍微不同的工作(如果重载的方法不应该用于这种情况,那么请停止我)。或者有时候你不能只用空值代替某些参数,如果某些参数为空,你希望抛出异常。在这种情况下,我不应该使用重载吗?

因此,基本上我正在寻找一些关于重载方法的指导方针,这些方法是在实现这些接口的抽象类中的接口和重载方法等方面。 在此先感谢

+0

如果您提供的合同承诺提供此方法的3个版本,那么您应该包括那些重载。 – 2011-01-26 05:50:57

+0

那么,是的,我知道,但问题的种类也包括这一点 - 我应该提供合同或不提供或有时或可能 – Dyppl 2011-01-26 05:55:56

+0

为什么我们不使用**默认参数**? – 2011-01-26 06:01:22

回答

8

如果默认值取决于方法调用的接收方,则将它们声明为接口方法。

如果默认值只是默认值而与接收者无关,那么创建各种简化参数列表重载作为扩展方法,并节省实现者必须自己提供所有重载的麻烦。

如果你处理的某种事实真相80/20法则有例外,实现独立的默认值是几乎但不完全总是足够的,你有几种选择,其中没有是很好的:

  • 处理它就好像它们总是不同,将它们声明为接口方法,并将它们重新实现。不是很干。
  • 处理它就好像它们总是不同,将它们声明为接口方法,并继承提供80%默认实现的基类。那种笨拙的,如果你唯一的基地级插槽已经被占用,那就不好。
  • 创建另一个包含这些特定方法的接口。声明与原始接口匹配的签名的扩展方法。在扩展方法中,as - 将this参数转换为新的接口类型,如果匹配,则在那里调用它,否则填写缺省值。非常时髦,依赖于动态转换,因此在内部循环中不那么好,但它将来自实现者和调用者的默认值解耦,而不牺牲不能采用“默认默认值”的实现者的灵活性。
0

IMO如果界面/合同拼出来,应该没有问题。然而,我们的目标是在暴露界面和隐藏细节时简化事情。那些可选的参数派上用场。像Python这样的面向对象的语言甚至没有超载AFAIK

1

如果接口的设计保证它的接口的重载方法可能正常。我个人从未需要这样做。

我不会在接口中定义默认参数值。这是一个实现细节,实现选择表面的类。

您对超载有不同的实现发表评论....

不要这样做。将这些重载方法的实现视为调用具有用某些默认值定义的所有参数的一个方法。这就是你的代码用户期望的事情。

如果你需要不同的行为,然后使用多态性。这就是它的目的。