Cannot access nested classes or members of base class

Question

I'm having some weird problems here with a Class that I've written. I cannot access anything inside of Account, unless I access it directly from Account.Whatever.

I'd like to be able to do:

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

but I can't. Nothing shows up in intellisense. I can only access things if I do:

Account. - for example, 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
        }
    }
}

I don't understand what's going on. Note, that I have also tried every possible combination of things but something is very wrong here. I've tried adding public to my Account class. I've tried adding public to my AccountHolder class. I've tried using public static etc etc etc.

I've never had this problem before. And why am I experiencing this same problem no matter how much I change it around?

The Account class is in an Account.cs file inside the same winforms project.

Answer 1

You are trying to access nested class, struct, enum. It should be done with the nesting class name, e.g. Account.Name.

But if you have

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

then you may access the MyName property using the instance of Account class.

Answer 2

One real question might be: Why do you need Nested Types here at all?

Nested types are especially used when no other types cannot reuse a type of your parent type, that is, if your nested type shall expose properties or values only applicable to your parent type. Otherwise it is mostly best to create independant types.

To me, it looks reasonable to think that you might use the Salutation enumeration outside of the AccountHolder class, as an Account Holder is nothing more than a legal entity, that is, a real person or a company.

If your system could use Salutation elsewhere, than it is best to create the enumeration per itself, in its own file, and expose a property out of your AccountHolder class.

Salutation

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

AccountHolder

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

In the later, one might also be insterested to know what's an account holder at once?

Might it be a company, a person, a customer, a supplier, or else?

Then perhaps shall you consider to define a hierarchy of account holders and make it a property of the most general class type.

LegalEntity

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

Company

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

Person

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...
}

Then, you have your Account class

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

So my point is that there is no use of Nested Types here, depending on your needs, which I'm not actually aware, obviously. And it turns out that an AccountHolder may now be of any types deriving from LegalEntity. Later on, when there is a need for another type of AccountHolder, you may simply derive from LegalEntity, or any other types which actually derives from it to make it an AccountHolder, as an AccountHolder is simply a property of an Account, and not a class per itself.

Some examples of using Nested Types adequately:

• Why Would I Ever Need to Use C# Nested Classes
• Why/when should you use nested classes in .net? Or shouldn't you?

Furthermore, you will need to make your Nested Types public in order to access them from outside of your class. This doesn't mean that will be able to avoid the Parent.NestedType nomenclature, you will not.

Apart from it, I see no problem in your code. Nested Types are by definition hidden somehow within another type. So when you wish to access them, you always need to type in the parent name which contains the type you need to access.

Plus, once you can access the Nested Type, you will be obliged to create members into your Account class to holde references to your instances of those Nested Types. IMHO, there is no gain of using them here. But hey, I insist, I'm not aware of your reality and the choices behind your design.

Answer 3

This is how the language works.

What you are probably wanting to use here are namespaces. Any nested class will always have to be fully qualified with its parent classes to be used. If you use a namespace, anything within that namespace can be used together without fully-qualifying, and can be used outside the namespace (within the bounds of access modifiers) by either fully-qualifying or by inserting a using directive (using Accounting; in this case).

Also, are you sure you want to be using a struct? Value types are immutable, so if you change any member of that struct, you're always creating an entirely new instance of the struct (generally significantly less efficient).

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
   }
}