Question

我有一个已经存在的泛型类

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

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

创建界面：

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());
}

传递一个Func：

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

第一种解决方案（即没有Func）要简单得多。绝对不需要调用Func对象来实现一个多样化的属性访问器。

Answer 2

我正在重新措辞我的答案，因为根据评论我意识到我不是很清楚。

这取决于您的代码的意图以及谁有责任为您的类命名（客户端应该知道并指定如何命名类与类本身应该具有名称）。我正在改变@ 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的内容，并且尝试问候任何其他内容应该是编译器捕获的类型错误。

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

示例2（Func）

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());

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

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

Answer 3

如果您的界面最终只使用一种方法，则使用Action或Func代表完全有效。那个更清洁的imho。

您不必写Invoke。只需用括号_funcName(_item)

调用它

Answer 4

代表在许多情况下会更方便实施者使用，因为vb.net和C＃编译器都包含使其易于使用的功能。接口可以执行委托不能做的事情（例如包括开放的泛型方法系列），并且在某些情况下可能比委托更有效（因为对实现接口的对象的引用可以作为该接口类型传递，而不必创建另一个用于保存它的堆对象）。然而，编译器支持轻松创建内联委托的事实，虽然没有提供单一功能接口的可比设施，但却提出了一个非常有利于前者的论据。

使用Func＆lt;＆gt;通过界面？

4 个答案:

示例1（接口）

示例2（Func）