【问题标题】:Use Generics or not?是否使用泛型?
【发布时间】:2011-11-17 13:00:12
【问题描述】:

有一个关于是否使用泛型的简单问题,如果是,这是正确的方法吗?

正常的非泛型版本如下:

    public interface IFood
{
    string name { get; set; }
}

public class Vegetables : IFood
{
    #region IFood Members

    public string name
    {
        get { return "Cabbage"; }
        set{ }
    }

    #endregion
}

public class Cow
{
    private IFood _food;

    public Cow(IFood food)
    {
        _food = food;
    }

    public string Eat()
    {
        return "I am eating " + _food.name;
    }
}

通用版本如下:

    public class Cow<T> where T : IFood
{
    private T _food;
    public Cow(T food)
    {
        _food = food
    }

    public string Eat()
    {
        return "I am eating " + _food.name;
    }
}

我在通用版本中做的一切正确吗?未来的增长是否需要使用通用版本?这只是原始场景的简单模型,但完全相似。

【问题讨论】:

  • 您是否需要一个与 Cow 完全分离的 Cow 类?或者现在可以给给定的奶牛喂谷物、玉米或任何其他可以用作动物饲料的绒毛吗?通用版本中的奶牛不是一回事,只不过 List 与 List 相同。另一方面,对我来说,牛就是牛。
  • @AnthonyPegram:这应该是一个答案
  • @AnthonyPegram 所以你不推荐使用通用版本,因为 Cow 与 Cow 不同。你能用一个适当的例子和答案部分简要解释一下吗,因为我想将它标记为答案,但在评论部分没有这样做

标签: c# .net


【解决方案1】:

我认为在这个具体示例中这是一个坏主意。

List&lt;int&gt; 通常被描述为 int 列表。 Cow&lt;IFood&gt; 更难描述 - 它肯定不是 IFood 的奶牛。这不是灌篮式的争论,但显示了一个潜在的问题。

MSDN 状态:

使用泛型类型来最大化代码重用、类型安全性和 性能。

在您的示例中,通用版本没有更多的代码重用,没有更多的类型安全性,也没有提高性能。

【讨论】:

    【解决方案2】:

    我认为使用泛型来执行行为规则是一个非常非常糟糕的主意。如果您只希望牛能够吃蔬菜,那么这更符合逻辑,并且应该通过逻辑规则来强制执行,而不是试图让编译器强制执行。因此,奶牛应该接受所有的食物,然后应用程序逻辑决定如果你给它除了它可以吃的东西之外的东西该怎么做。

    一个很好的例子是如果你决定添加干草作为牛可以吃的东西,没有办法使用泛型说你可以给牛蔬菜或干草,除非你创建一个 IVegetableOrHay 接口,这应该会让我们都想杀了那头牛,然后把它当晚餐吃。

    编译器类型强制是为了确保正确的程序结构。应用逻辑属于代码。

    【讨论】:

      【解决方案3】:

      您想使用泛型扩展/实现子类功能吗?那么这不是通用的目的。您将在所有类型的对象具有相同目的的情况下使用泛型。比如序列化。在这里,如果你使 COW 通用,那么你必须在 COW 中实现 COW 功能的子类。这不会是对另一个子类的拒绝遗赠。这里 COW 可能是超类而不是泛型。我的建议是对不同的类族使用泛型。不在同一个班级里。

      【讨论】:

        猜你喜欢
        • 2014-08-19
        • 2013-03-01
        • 1970-01-01
        • 1970-01-01
        • 2020-06-28
        • 1970-01-01
        • 1970-01-01
        • 2017-04-11
        • 1970-01-01
        相关资源
        最近更新 更多