7

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

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，这就是我问自己的原因！

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

4

4 回答 4

3

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

于 2012-07-30T15:23:04.250 回答
3

如果您的界面最终只有一种方法，那么使用Action或Func委托是完全有效的。这更清洁恕我直言。

不过你不必写Invoke。只需用括号调用它：_funcName(_item)

于 2012-07-30T15:38:44.160 回答
3

我正在重新表述我的答案，因为从评论中我意识到我并不是很清楚。

这取决于您的代码的意图以及谁有责任为您的类命名（客户端应该知道并指定如何命名类，而类本身应该有一个名称）。我正在稍微更改@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（功能）

class AThing {}
class AnotherUnrelatedThing {}

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

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

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

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

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

于 2012-07-30T15:38:57.837 回答
2

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

于 2012-07-30T22:28:03.827 回答