【问题标题】:Cannot access nested classes or members of base class无法访问嵌套类或基类成员
【发布时间】:2014-08-04 16:31:20
【问题描述】:

我写的一个类在这里遇到了一些奇怪的问题。我无法访问Account 中的任何内容,除非我直接从Account.Whatever 访问它。

我希望能够做到:

Account account = new Account();
account.Name...

但我不能。智能感知中没有任何显示。如果我这样做,我只能访问东西:

Account. - 例如,Account.AccountHolder...

class Account
{
    class AccountHolder
    {
        enum Salutation
        {
            Mr,
            Mrs,
            Ms,
            Miss,
            Dr,
            Hon
        }

        struct Name
        {
            public string FirstName { get; set; }
            public string MiddleName { get; set; }
            public string LastName { get; set; }
        }

        enum Sex
        {
            Male,
            Female
        }
    }
}

我不明白发生了什么。请注意,我也尝试了所有可能的组合,但这里有些问题。我尝试将public 添加到我的帐户类。我尝试将 public 添加到我的 AccountHolder 类中。我试过使用public static等等等等。

我以前从未遇到过这个问题。为什么无论我如何改变它都会遇到同样的问题?

Account 类位于同一 winforms 项目内的 Account.cs 文件中。

【问题讨论】:

  • 您使用的是什么版本的 Visual Studio?
  • @FarhadJabiyev 请忽略这个错误。我想在我的问题中写的是 account.AccountHolder...。
  • @bytebender 我正在使用 Visual Studio 2014 Ultimate CTP。但是我已经使用了大约一个月了,这是我第一次遇到这个问题。

标签: c# .net winforms


【解决方案1】:

一个真正的问题可能是:你为什么需要Nested Types

当没有其他类型不能重用您的父类型的类型时,特别使用嵌套类型,也就是说,如果您的嵌套类型应公开仅适用于您的父类型的属性或值。否则,最好创建独立类型。

对我来说,认为您可以在 AccountHolder 类之外使用 Salutation 枚举似乎是合理的,因为帐户持有人只不过是一个法人实体,即一个真实的人或一家公司。

如果您的系统可以在其他地方使用 Salutation,那么最好在其自己的文件中单独创建枚举,并在您的 AccountHolder 类之外公开一个属性。

致意

public enum Salutation {
    Mr
    , Mrs
    , Ms
    , Miss
    , Dr
    , Hon
}

账户持有人

public class AccountHolder {
    public Salutation Salutation { get; set; }
    // ...
}

在以后,可能还会有兴趣了解什么是帐户持有人?

可能是公司、个人、客户、供应商还是其他?

那么也许您应该考虑定义帐户持有人的层次结构,并将其作为最通用类类型的属性。

法人实体

public class LegalEntity {
    public string Name { get; set; }
}

公司

public class Company : LegalEntity {
    // Some members specific to a Company here...        
}

人物

public class Person : LegalEntity {
    public Salutation Salutation { get; set; }
    public string FirstName { get; set; }
    public string MiddleName { get; set; }
    public string LastName { get { return base.Name; } set { base.Name = value; } }
    // Some other members specific to a person here...
}

那么,你就有了你的Account

public class Account {
    public LegalEntity AccountHolder { get; set; }
}

所以我的意思是,这里没有使用 嵌套类型,这取决于您的需要,显然我实际上并没有意识到这一点。事实证明,AccountHolder 现在可能是派生自LegalEntity 的任何类型。稍后,当需要另一种类型的AccountHolder 时,您可以简单地从LegalEntity 或任何其他实际派生自它的类型使其成为AccountHolder,因为AccountHolder 只是一个Account 的属性,而不是一个类本身。

充分使用Nested Types 的一些示例:

此外,您需要公开您的嵌套类型,以便从课堂外访问它们。这并不意味着可以避免 Parent.NestedType 命名法,你不会。

除此之外,我认为您的代码没有问题。根据定义,嵌套类型以某种方式隐藏在另一种类型中。因此,当您希望访问它们时,您始终需要输入包含您需要访问的类型的父名称。

另外,一旦您可以访问嵌套类型,您就必须在 Account 类中创建成员,以保存对这些嵌套类型实例的引用。恕我直言,在这里使用它们没有任何好处。但是,嘿,我坚持说,我不了解您的现实以及您设计背后的选择。

【讨论】:

  • 非常感谢@Will 的详细回答,这样好多了。
【解决方案2】:

您正在尝试访问嵌套的classstructenum。应该使用嵌套类名来完成,例如Account.Name.

如果你有

class Account
{
    public struct Name
    {
        public string FirstName { get; set; }
        public string MiddleName { get; set; }
        public string LastName { get; set; }
    }

    public Name MyName {get; set;}
}

那么您可以使用Account 类的实例访问MyName 属性。

【讨论】:

  • 谢谢@Alex。我不敢相信。你让我意识到我实际上做的事情和我平时做的不一样。这很奇怪,因为除非有理由,否则我通常不会做不同的事情。而且我不记得这次是有原因的。最近我的大脑很奇怪。
【解决方案3】:

这就是语言的工作原理。

您可能想在这里使用的是命名空间。任何嵌套类都必须完全限定其要使用的父类。如果您使用命名空间,则该命名空间内的任何内容都可以在没有完全限定的情况下一起使用,并且可以通过完全限定或插入 using 指令(@987654322 @ 在这种情况下)。

另外,您确定要使用结构吗?值类型是不可变的,因此如果您更改该结构的任何成员,您总是会创建一个全新的结构实例(通常效率会大大降低)。

namespace Accounting
{
   class Account
   {
      public PersonName Name { get; set; }
      public Sexes Sex { get; set; }
      public Salutations Salutation { get; set; }
   }

   class PersonName
   {
      public string First { get;set; }
      public string Middle { get; set; }
      public string Last { get; set; }
   }

   enum Salutations : byte
   {
      Mr,
      Mrs,
      Ms,
      Miss,
      Dr,
      Hon
   }

   enum Sexes : byte
   {
      Male,
      Female
   }
}

【讨论】:

  • 谢谢@dodecahedron,我对结构一无所知。我过去很少使用它们。
  • 刚刚用一个代码示例更新了答案,说明应该如何布局。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-01-25
  • 2013-11-14
  • 1970-01-01
  • 1970-01-01
  • 2012-10-18
相关资源
最近更新 更多