Question

假设我有一节课可以获得有关体育比分，球队等的各种信息：

public class SportsInfo
{
    GameResult GetResult(string date, string homeTeam){...}
    TeamRecord GetRecord(string teamName){...}

    public class GameResult
    {
        public int HomeTeamScore { get; set; }
        public int AwayTeamScore { get; set; }
    }

    public class TeamRecord
    {
        public int Wins { get; set; }
        public int Losses{ get; set; }
    }
}

我在网上看到的大多数建议似乎是嵌套类通常应该是私有的，并且仅用于仅在包含类中有意义的类型。但是，在这种情况下，返回类型非常小，基本上只是美化的键值对。另一种选择是将它们分解为非嵌套类，但在许多环境中，预计每个文件只有1个类，这意味着我将拥有一个完整的文件，包括头文件和其他开销只是为了定义一个类只有2个自动属性。对我来说，这使得导航，构建甚至理解代码变得更加困难，而且类很容易看到，嵌套在父SportsInfo类中。

这是否有任何公认的最佳做法？显然，如果返回类型的数量或大小增加得足够多，它会干扰SportsInfo.cs的清晰度，然后应该打破。但是如果记录这么简单，那就不像上面所描述的那样容易和清晰了吗？

Answer 1

作为数据持有者的嵌套类对我有意义。但是，您需要考虑其他几个因素。

该示例仅显示标量内容，在这种情况下，使用结构使其具有类似值更好吗？
在这些课程中，你已经展示了setter，但如果它们是不可变的，那不是更好吗？
如果有参考值字段并且它们不是不可变的，那么您不需要复制构造函数吗？
如果A调用B和B返回一个值而A期望该值，则它们之间存在契约，但在嵌套类中，契约是单方面的。
您如何根据接口而不是具体类来协调此策略与定义合同？

我想我所说的是在标量字段和/或具有实现实现的不可变值的（相对）狭窄情况下它看起来没问题。我怀疑，当你突破那个利基市场时，他们会造成比他们的价值更多的麻烦。 YMMV。

Answer 2

Framework design guidelines说

AVOID 公开公开的嵌套类型。唯一的例外是如果嵌套类型的变量只需要很少声明子类化或其他高级自定义等方案场景。
如果类型可能在包含类型之外引用，请不要使用嵌套类型。

所以，对公共嵌套类型说不。

Answer 3

要在上一个提到MS设计指南的答案中添加更多内容：

嵌套类型的目的是访问它的封闭类型私有详细信息，作为实现和目标复杂类型实现方案的一部分，例如内部状态，实现其他公共接口的高度耦合集合或子类化公共类型等。

在你的情况下，GameResult和TeamRecord是数据对象，因此不会受益于嵌套，同时你的类的使用者将具有较少的可读性和可维护性代码。因此，在这里使用嵌套类是不必要的，适得其反。

嵌套类是否应该用于定义数据访问的简单返回类型？

3 个答案: