是否利用可选参数边缘情况通过语言的接口滥用强制实现 ToString？

Question

我有一个接口 IKey 我想要一个方法将密钥作为字符串返回。我们考虑过有一个这样的方法：

String GetAsString();

它将返回字符串表示形式，但希望能够在接口中再次声明 ToString() 以强制实现者实现它，但事实并非如此。不要强迫它们这样做，因为它们有一个继承自 Object 的实现。建议这样做：

public interface IKey
{
    string ToString(string dummyParameter=null);
}

这会强制在任何实现类中实现该方法，但由于 可选参数的工作方式 调用者不需要为此提供值，并且您确保对转换为接口 IKey 或实现类的对象上的 ToString() 方法将始终调用类实现，而不是 Object 实现。

在实现中，我们可以忽略 dummyParameter 并返回我们想要的内容，因为调用 ToString() 将始终实际调用 ToString(null)< /代码>。

现在我觉得这一切都是错误的，但同时它确实有一些很好的东西。它与方法 GetAsString() 几乎完全相同，因为它只能在 IKey 接口和派生类上调用，只是它看起来更自然 ToString() 我们想要使用的方法，并且我们能够在子类中强制实现该方法。

话虽如此，未使用的虚拟参数感觉不对。

那么这可怕吗？还是很棒？

这个问题适合 SO 还是应该适合程序员？

示例

public class Key :IKey 
    { 
        public string ToString(string abc = null) 
        { 
            return "100"; 
        } 
    }

Key key = new Key ();
Trace.WriteLine (key.ToString());
Trace.WriteLine (key.ToString(null));
Trace.WriteLine (key.ToString("ac"));
Trace.WriteLine (((object)key).ToString());

输出：

100
100
100
Blah.Tests.Key

Answer 1

听起来您正在使用一个应该使用抽象类的接口。下面的类明确要求后代实现 ToString。

abstract class X
{
    public abstract override string ToString();
}

Answer 2

从我的角度来看，自定义接口中的此类 ToString() 方法稍微搞乱了事情，因为自定义接口公开了一个具有标准且众所周知的名称 ToString() 的方法。

我更喜欢更直接和明显的方法，例如：

string KeyText { get; }

OR 方法

string ConvertKeyToString();

Answer 3

另一个答案已经建议使用抽象类，我认为这是最好的选择。

在接口中添加带有默认参数的 ToString 的想法在实践中效果不太好。当不带参数调用时，重载解析将找到不带参数的 ToString（我必须说，这看起来很直观）。考虑该程序的输出：

void Main()
{   
    Console.WriteLine(new Key().ToString());
}

public interface IKey 
{
    string ToString(string dummy = null);
}

class Key : IKey 
{   
    public string ToString(string dummy) 
    {
        return "myspecialKey";
    }
}

这输出了 object.ToString() 实现。因此，如果您被限制使用接口，我会将该方法命名为 ToString() 之外的其他名称。

Answer 4

重新利用

(IMO) -ToString() 已经有了非常明确的目的和含义。根据名称劫持它可能对您来说很方便，但是通过说这是必需的，您正在重新利用一些不应该使用的东西。

答案是有自己独立的方法，最初的想法。任何其他内容都意味着所有有关 ToString() 的 .NET 文档都将变得“错误”。

例如，Tag 属性是许多 UI 控件上的一个对象。您可能想在某种控件库中“标记”控件。仅仅因为名称合适、类型合适，并不意味着含义相同，您可以抓住它并重新利用它。

命名

我还建议考虑更改您的界面名称；除非实施者实际上是关键？我的印象是它们只是“有钥匙”，或者有一些与之相关的钥匙。在这种情况下，IKeyed、IIndexed 或其他东西可能会更好。然后是一个string Key { get; } 变得更具吸引力。也许这只是命名问题。？

Answer 5

我会称之为滥用，因为你在这里暗示的问题：

...并且您确保对转换为接口 IKey 或实现类的对象上的 ToString() 方法的任何调用将始终调用类实现而不是对象实现。

考虑以下代码：

IKey someKey = ...;
string keyAsString = someKey.ToString();
object someKeyAsObject = (object)someKey;
string keyAsString2 = someKeyAsObject.ToString();

任何查看此代码的人都会假设 keyAsString 和 keyAsString2 是相同的。但是，这些将调用可能具有不同行为的不同方法。哎呀！

Answer 6

太可怕了，如果我必须选一个词的话……如果我在野外遇到这种情况，困惑和怀疑会更准确地描述我的反应。

在设计 API 时，我尝试遵循一条最重要的规则：不要让开发人员感到惊讶。

这肯定会让人感到惊讶。它排除了使用预期输出和使用ToString()而无需特殊努力。事实上，没有迹象表明需要特殊的努力，这将是一个“惊喜”。 ToString() 的默认实现最终的使用频率比我预期的要高。除非我没有其他合理的方法来解决问题，否则我会避免禁止或扭曲其使用。

我认为这不会比尚未成为 object 成员的命名良好的方法/属性“更自然”。

Answer 7

刚刚遇到这个。让接口继承IFormattable怎么样？

http://msdn.microsoft.com/en-us/library/system .iformattable.aspx

我自己没有这样做过，所以我可能是错的，但这似乎可以为您的界面的 ToString 方法使用格式参数。请注意，您仍然没有更改无参数 ToString，我同意其他人不应该在界面中完成此操作，而是使用 ToString(string format, IFormatProviderprovider) 使用可识别的格式输入，基本上意味着“在该对象实现 IWhatever 的上下文中给我一个描述”。显然，每个实现的类都需要对方法进行编码，但这是正确的。