在界面上使用Func <>？

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 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 接口的合约保证的）。在这里，您要保证 Foo 仅适用于具有名称的事物，并且尝试迎接其他任何事物应该是编译器捕获的类型错误。

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

示例 2（函数）

class AThing {}
class AnotherUnrelatedThing {}

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

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

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

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

因此，根据您想要表达的内容，以及如果您有一个具有名称（无论 Foo 是什么）的对象层次结构，您可以选择其中一种方式。