有关IInterface设计的问题... [英] A question on IInterface design...

问题描述

大家好，
我在设计自己拥有的Interface 时遇到了一些问题(不是GUI).
我基本上有两个相同的Interfaces ，但是其中一个需要为Function获取一个额外的参数.

Hi all,
I''m having a little problem designing an Interface I have (not the GUI).
What I basically have is two Interfaces that do the same, but one of them needs to get an extra parameter to a Function.

Public Interface IDoSomething(Of T)
    Function DoSomething(ByVal something As T) As String
End Interface

Public Interface IDoSomethingSlightlyDifferently(Of T)
    Inherits IDoSomething(Of T)
    Function DoSomething(ByVal s As String, ByVal something As T) As String
End Interface

以上并非不可能，但IDoSomethingSlightlyDifferently 现在有一个重载DoSomething Function.一个永远不会被称为...
IDoSomething 由用户使用和实现，另一个Class 使用IDoSomething 作为输入参数.
要从某些Reflection 代码(调用重载函数)中调用IDoSomethingSlightlyDifferently .

因此，尽管两个Interfaces 服务于相同的目的，但它们的调用方式却不同.这是否意味着一个人不应该Inherit 另一个人?还是我应该继承它们，而只是拥有一个抛出<code> NotImplementedException的空Function ?

实际上，当我写这篇文章时，我想我找到了自己的答案. IDoSomething 和IDoSomethingSlightlyDifferent 可能永远不可互换.您要么一个都不会被调用，要么另一个都不会被调用，或者您现在都有一个执行两个功能的Class (它们看起来相同，但仍然略有不同).所以我想答案是他们不应该Inherit.

我仍然很好奇，期待您对此事发表一些意见.这已经困扰了我一段时间了.
谢谢.

The above is not impossible, but the IDoSomethingSlightlyDifferently now has an overload for the DoSomething Function. One that will never be called...
The IDoSomething is to be used and implemented by the user and another Class uses IDoSomething as an input parameter.
IDoSomethingSlightlyDifferently is to be called from some Reflection code (which calls the overloaded function).

So while both Interfaces serve the same purpose the manner in which they are called is different. Does that mean one should not Inherit the other? Or should I Inherit them and simply have an empty Function that throws a <code>NotImplementedException?

Actually, as I wrote this I think I found my own answer. IDoSomething and IDoSomethingSlightlyDifferent are probably never interchangeable. You either Implement one and the other will never be called or you Implement both and you now have a Class that does two things (which look the same, but are still slightly different). So I guess the answer is they shouldn''t Inherit.

I''m still curious and looking forward to some of your opinions on this matter. It''s something that has been bugging me for a while.
Thanks.

推荐答案

我在这里看不到任何问题.接口可以从另一个继承或不从另一个继承.一个类或结构可以实现这两个或两者之一.如何精确构建此层次结构取决于所有这些类型的应用程序，而不取决于示例中显示的方法的签名，并且请注意！ —关于这两种方法的名称.

您在这里只犯了一个错误:您说一个……永远不会被呼叫".这不是真的.为了理解这一点，请花一分钟的时间，为您调用DoSomething的两个方法提供两个截然不同的名称.在这种情况下，您会看到任何问题吗?我的说法是:如果给这两种方法使用相同的名称或两个不同的名称，它完全没有区别.在所有情况下都没有任何区别.

为什么?要理解它，足以注意到它们具有不同数量的参数，并且没有可选参数(在C#v.4中引入). (这是足够的，但不是必需的条件.)在任何情况下，编译器都无法确定对哪个函数的隐式调用.但是，即使在某些情况下call语句有歧义，也始终可以对任何同名方法(以一种声明类型)使用该调用.

为了完成这一点，我想作一个一般性说明.我了解重载方法"一词，但请尝试自己不要使用它.这是该行业中最令人误解的术语之一(另一个是竞赛条件"；如果没有实际了解该术语下所理解的内容，几乎不可能就其含义做出正确的猜测).某人因不幸而创造的重载方法"并不意味着任何实质性的内容.碰巧的是，在较旧的编程语言中，他们的作者要求不同的函数具有截然不同的名称，以使编译器更简单.后来，人们决定为该语言的用户提供更多便利.没有什么过载"，仅仅是因为这里没有过载".

问题在于，一些愚蠢的活动正在围绕这个琐碎的观念进行. "override"和"overload"之间的相似性使这种臭味燃烧.在CodeProject上，我什至看到了有关与重载"相关联的编译时多态性"的猜测，而不是与覆盖相关联的运行时多态性"的猜测.一个简单的原因就没有与"overloadinig"相关的任何类型的多态性:没有作为现象的"overloading"之类的东西.名称相同但签名不同的两种不同方法的行为完全相同，就好像它们的名称不同.我试图揭穿这个神话，但也许这是一个很普遍的神话，其中一个世代相传却没有任何批判性思维.

—SA

I see no problem here at all. The interfaces may inherit one from another or not. A class or a structure can implement either of the two or both of them. How exactly you build this hierarchy depends on the application of all those types and does not depend on signatures of the methods you show in your sample and — pat attention! — on the names of these two methods.

You do only one mistake here: you say "one… will never be called". This is not true. To understand it, for a minute, give your two methods you called DoSomething two distinctly different names. Will you see any problem in this case? My statement is: it makes no difference at all if you give the same name or two different names to these two method. No difference at all, in all cases.

Why? To understand it, it''s enough to note that they have different number of parameters and no optional parameters (introduced in C# v.4). (This is sufficient but not necessary condition.) There are no situations where a compiler cannot determine a call to which of the function is implied. But even when there are cases where a call statement has some ambiguity, the use of the call to any of the methods of the same name (in one declaring type) is always possible.

To complete this, I want to give one general note. I understand the term "overloaded method", but try to never use it myself. This is one of the most misleading terms in the industry (another one is "race condition"; without actual knowledge on what is understood under this term it''s nearly impossible to make a correct guess on what is it). "Overloaded method", coined by someone by a bad luck, does not really mean anything material. It''s just so happened that in older programming language, their authors required that different functions had distinctly different names, just to make compilers simpler. Later on, people decided to give more convenience to the users of the language. There is nothing "overloaded" simply because nothing is "loaded" here.

The problem is that some idiotic activity is running around this trivial notion. The similarity between "override" and "overload" keeps this smelly fire burning. On CodeProject, I even saw the speculations about "compile-time polymorphism" associated with "overloading" as opposed to "run-time polymorphism" associated with overriding. There is nothing like any kind of polymorphism related to "overloadinig" by one simple reason: there is no such thing as "overloading" as a phenomenon. Two different methods with identical names but different signature behave in exact same was as if the were named differently. I tried hard to debunk this myth, but probably this is one pretty common myth, one of those passed through generations without any critical thinking applied to it.

—SA

这篇关于有关IInterface设计的问题...的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！