c# - 在接口(interface)上使用 Function<>？

Question

我有一个已经存在的通用类

public class Foo<T>
{
    private T _item;
    public Foo(T item){ _item = item;}
}

我必须创建一个方法来返回 T 的某个属性。
我在这里看到两个解决方案。

1. 创建界面:

   public const string TestVar = "bar";
   public interface INamable { string Name { get; } }
   public class Bar : INamable
   {
       public string Name { get { return TestVar; } }
   }
   
   public class Foo<T> where T : INamable
   {
       private T _item;
       public Foo(T item) { _item = item; }
       public string GetName() { return this._item.Name; }
   }
   
   [TestMethod()]
   public void TestInterface()
   {
       var bar = new Bar();
       var foo = new Foo<Bar>(bar);
       Assert.AreEqual(TestVar, foo.GetName());
   }
   

2. 传递函数:

   public const string TestVar = "bar";
   public class Bar
   {
       public string Name { get { return TestVar; } }
   }
   
   public class Foo<T>
   {
       private T _item;
       private Func<T, string> _funcName;
       public Foo(T item, Func<T, string> funcName) { _item = item; _funcName = funcName; }
       public string GetName() { return _funcName.Invoke(_item); }
   }
   
   [TestMethod()]
   public void TestFunc()
   {
       var bar = new Bar();
       var foo = new Foo<Bar>(bar, b => b.Name);
       Assert.AreEqual(TestVar, foo.GetName());
   }
   

我选择第二种解决方案，因为我不必创建界面，而且我很懒。只需向 foo 构造函数的已调用添加一个参数即可。

此外，Foo 类仍然可以与各种类一起使用，我更喜欢这种方式。

但是，我不确定这是否是使用 Func 的好方法？它仍然很好而且坚固吗？这是我第一次尝试使用 Func，这就是我问自己的原因!

几个月前，我使用了第一个解决方案，具有经典界面...

Answer 1

我正在重新措辞我的回答，因为从评论中我意识到我不是很清楚。

这取决于您的代码的意图以及谁负责为您的类命名(客户应该知道并指定如何命名类与类本身应该有一个名称)。我正在稍微更改@Scorpi0 的示例，以便 Foo 实际上用名称做一些事情(它向它打招呼)而不是仅仅返回它。

示例1(接口(interface))

interface INamable { string Name { get; } }

class AThingWithAName : INamable 
{
    public string Name {get {return "thing";}}
}

class AnotherThingWithAName : INamable 
{
    public string Name {get {return "different thing";}}
}

class Foo<T> where T : INamable
{
    public string Greet(T item) {return "hi " + item;}
}

在这里，无论 Foo 是什么，事物都有一个名称。 Foo 知道如何打招呼，只要他们有一个名字(这是由他们实现 INamable 接口(interface)的契约(Contract)保证的)。在这里，您要保证 Foo 仅适用于具有 Name 的事物，并且尝试问候任何其他事物应该是编译器捕获的类型错误。

另外，请注意您在每个类中封装了 Name 的具体实现。名称可能取决于其类的私有(private)状态。

示例 2(函数)

class AThing {}
class AnotherUnrelatedThing {}

class Foo<T>
{
    public string Greet(T item, Func<T, string> namingFunction) 
    {
        return "hi " + namingFunction(item);
    }
}

这里重点是Foo。事物不一定有名字。我想建立一个可以迎接任何事物的类 Foo 。它是如何做到的？好吧，对于任何类型，调用者都有责任传入一个可以为该类型命名的函数。在这种情况下，我们不仅不要求保证 T 知道它自己的名称，而且我们正在构建 Foo，只要我们知道如何给它一个名称，它就可以迎接任何类型。例如这有效:

var foo = new Foo<int>();
var res=foo.Greet(2, n=>n.ToString());

为了换取这种灵 active ，我们放弃了封装。现在 Name 不再是类负责实现的东西，我们(调用者)告诉 Foo 如何给我们使用它的每个类命名。

因此，根据您想要表达的内容，如果您有一个名称与 Foo 无关的对象层次结构，您可以选择其中一种方式。