The following BankAccount class example declares all its methods public but declares its data members, including _accountNumber and _balance, to be private. Note that I've left it in an incorrect state to make a point. The following code chunk doesn't compile correctly yet:

// BankAccount -- Create a bank account using a double variable
//    to store the account balance (keep the balance in a private
//    variable to hide its implementation from the outside world).
// Note: Until you correct it, this program fails to compile
// because Main() refers to a private member of class BankAccount.
using System;
namespace BankAccount
{
  public class Program
  {
    public static void Main(string[] args)
    {
      Console.WriteLine("This program doesn't compile in its present state.");
      // Open a bank account.
      Console.WriteLine("Create a bank account object");
      BankAccount ba = new BankAccount();
      ba.InitBankAccount();
      // Accessing the balance via the Deposit() method is okay --
      // Deposit() has access to all the data members.
      ba.Deposit(10);
      // Accessing the data member directly is a compile-time error.
      Console.WriteLine("Just in case you get this far the following is "
                      + "supposed to generate a compile error");
      ba._balance += 10;
      // Wait for user to acknowledge the results.
      Console.WriteLine("Press Enter to terminate...");
      Console.Read();
    }
  }

  // BankAccount -- Define a class that represents a simple account.
  public class BankAccount
  {
    private static int _nextAccountNumber = 1000;
    private int _accountNumber;
    // Maintain the balance as a double variable.
    private double _balance;
    // Init -- Initialize a bank account with the next
    //    account id and a balance of 0.
    public void InitBankAccount()
    {
      _accountNumber = ++_nextAccountNumber;
      _balance = 0.0;
    }
    // GetBalance -- Return the current balance.
    public double GetBalance()
    {
      return _balance;
    }

// AccountNumber
    public int GetAccountNumber()
    {
      return _accountNumber;
    }
    public void SetAccountNumber(int accountNumber)
    {
      this._accountNumber = accountNumber;
    }
    // Deposit -- Any positive deposit is allowed.
    public void Deposit(double amount)
    {
      if (amount > 0.0)
      {
        _balance += amount;
      }
    }
    // Withdraw -- You can withdraw any amount up to the
    //    balance; return the amount withdrawn.
    public double Withdraw(double withdrawal)
    {
      if (_balance <= withdrawal)
      {
        withdrawal = _balance;
      }
      _balance -= withdrawal;
      return withdrawal;
    }
    // GetString -- Return the account data as a string.
    public string GetString()
    {
      string s = String.Format("#{0} = {1:C}",
                                GetAccountNumber(), GetBalance());
      return s;
    }
  }
}

Marking a member public makes that member available to any other code within your program.

The BankAccount class provides an InitBankAccount() method to initialize the members of the class, a Deposit() method to handle deposits, and a Withdraw() method to perform withdrawals. The Deposit() and Withdraw() methods even provide some rudimentary rules, such as "You can't deposit a negative number" and "You can't withdraw more than you have in your account" (both good rules for a bank, as I'm sure you'll agree). However, everyone's on the honor system as long as _balance is accessible to external methods. (In this context, external means "external to the class but within the same program.") The honor system can be a problem on big programs written by teams of programmers. It can even be a problem for you (and me), given general human fallibility.

Before you get too excited, however, notice that the program doesn't build. Attempts to do so generate this error message:

'BankAccount.BankAccount._balance' is inaccessible due to its protection level.

I don't know why it doesn't just come out and say, "Hey, this is private, so keep your mitts off." The statement ba._balance += 10; is illegal because _balance isn't accessible to Main(), a method outside the BankAccount class. Replacing this line with ba.Deposit(10) solves the problem. The BankAccount.Deposit() method is public and therefore accessible to Main() and other parts of your program.

C# provides these levels of security:

Keeping a member hidden by declaring it private offers the maximum amount of security. However, in many cases, you don't need that level of security. After all, the members of a subclass already depend on the members of the base class, so protected offers a comfortable level of security.

If you look more carefully at the BankAccount class, you see a few other methods. One, GetString(), returns a string version of the account fit for presentation to any Console.WriteLine() for display. However, displaying the contents of a BankAccount object may be difficult if its contents are inaccessible. The class should have the right to decide how it is displayed.

In addition, you see two "getter" methods, GetBalance() and GetAccountNumber(), and one "setter" method, SetAccountNumber(). You may wonder why I would bother to declare a data member such as _balance private but provide a public GetBalance() method to return its value. I have two reasons:

Finally, GetBalance() provides a mechanism for making internal changes to the class without the need to change the users of BankAccount. If the Federal Deposit Insurance Corporation (FDIC) mandates that your bank store deposits differently, the mandate shouldn't change the way you access your account.

The following DoubleBankAccount program demonstrates a potential flaw in the BankAccount program. The entire program is on your Web site; however, the following listing shows just Main() — the only portion of the program that differs from the earlier BankAccount program:

// DoubleBankAccount -- Create a bank account using a double variable
//    to store the account balance (keep the balance in a private
//    variable to hide its implementation from the outside world).
using System;
namespace DoubleBankAccount
{

public class Program
  {
    public static void Main(string[] args)
    {
      // Open a bank account.
      Console.WriteLine("Create a bank account object");
      BankAccount ba = new BankAccount();
      ba.InitBankAccount();
      // Make a deposit.
      double deposit = 123.454;
      Console.WriteLine("Depositing {0:C}", deposit);
      ba.Deposit(deposit);
      // Account balance
      Console.WriteLine("Account = {0}", ba.GetString());
      // Here's the problem.
      double fractionalAddition = 0.002;
      Console.WriteLine("Adding {0:C}", fractionalAddition);
      ba.Deposit(fractionalAddition);
      // Resulting balance
      Console.WriteLine("Resulting account = {0}", ba.GetString());
      // Wait for user to acknowledge the results.
      Console.WriteLine("Press Enter to terminate...");
      Console.Read();
    }
  }

The Main() method creates a bank account and then deposits $123.454, an amount that contains a fractional number of cents. Main() then deposits a small fraction of a cent to the balance and displays the resulting balance.

The output from this program appears this way:

Create a bank account object
Depositing $123.45
Account = #1001 = $123.45
Adding $0.00
Resulting account = #1001 = $123.46
Press Enter to terminate...

Users start to complain: "I just can't reconcile my checkbook with my bank statement." Personally, I'm happy if I can get to the nearest $100, but some people insist that their accounts match to the penny. Apparently, the program has a bug.

The problem, of course, is that $123.454 shows up as $123.45. To avoid the problem, the bank decides to round deposits and withdrawals to the nearest cent. Deposit $123.454 and the bank takes that extra 0.4 cent. On the other side, the bank gives up enough 0.4 amounts that everything balances out in the long run. Well, in theory, it does.

The easiest way to solve the rounding problem is by converting the bank accounts to decimal and using the Decimal.Round() method, as shown in this DecimalBankAccount program:

// DecimalBankAccount -- Create a bank account using a decimal
//     variable to store the account balance.
using System;
namespace DecimalBankAccount
{
  public class Program
  {
    public static void Main(string[] args)
    {
      // Open a bank account.
      Console.WriteLine("Create a bank account object");
      BankAccount ba = new BankAccount();
      ba.InitBankAccount();
      // Make a deposit.
      double deposit = 123.454;
      Console.WriteLine("Depositing {0:C}", deposit);
      ba.Deposit(deposit);
      // Account balance
      Console.WriteLine("Account = {0}", ba.GetString());
      // Now add in a very small amount.
      double fractionalAddition = 0.002;
      Console.WriteLine("Adding {0:C}", fractionalAddition);
      ba.Deposit(fractionalAddition);
      // Resulting balance.
      Console.WriteLine("Resulting account = {0}", ba.GetString());
      // Wait for user to acknowledge the results.
      Console.WriteLine("Press Enter to terminate...");
      Console.Read();
    }
  }
  // BankAccount -- Define a class that represents a simple account.
  public class BankAccount
  {
    private static int _nextAccountNumber = 1000;
    private int _accountNumber;
    // Maintain the balance as a single decimal variable.
    private decimal _balance;
    // Init -- Initialize a bank account with the next
    //    account id and a balance of 0.
    public void InitBankAccount()
    {
      _accountNumber = ++_nextAccountNumber;
      _balance = 0;
    }
    // GetBalance -- Return the current balance.
    public double GetBalance()
    {
      return (double)_balance;
    }
    // AccountNumber
    public int GetAccountNumber()
    {
      return _accountNumber;
    }
    public void SetAccountNumber(int accountNumber)
    {
      this._accountNumber = accountNumber;
    }
    // Deposit -- Any positive deposit is allowed.
    public void Deposit(double amount)
    {

if (amount > 0.0)
      {
        // Round off the double to the nearest cent before depositing.
        decimal temp = (decimal)amount;
        temp = Decimal.Round(temp, 2);
        _balance += temp;
      }
    }
    // Withdraw -- You can withdraw any amount up to the
    //    balance; return the amount withdrawn.
    public double Withdraw(double withdrawal)
    {
      // Convert to decimal and work with the decimal version.
      decimal decWithdrawal = (decimal)withdrawal;
      if (_balance <= decWithdrawal)
      {
        decWithdrawal = _balance;
      }
      _balance -= decWithdrawal;
      return (double)decWithdrawal;  // Return a double.
    }
    // GetString -- Return the account data as a string.
    public string GetString()
    {
      string s = String.Format("#{0} = {1:C}",
                               GetAccountNumber(), GetBalance());
      return s;
    }
  }
}

I've converted all internal representations to decimal values, a type better adapted to handling bank account balances than double in any case. The Deposit() method now uses the Decimal.Round() method to round the deposit amount to the nearest cent before making the deposit. The output from the program is now as expected:

Create a bank account object
Depositing $123.45
Account = #1001 = $123.45
Adding $0.00
Resulting account = #1001 = $123.45
Press Enter to terminate...

You could argue that I should have written the BankAccount program using decimal input arguments to begin with, and I probably would agree. But the point is that I didn't. Other applications were written using double as the form of storage. A problem arose. The BankAccount class was able to fix the problem internally and make no changes to the application software. (Notice that the class's public interface didn't change: Balance() and Withdraw() still return doubles, and Deposit() and Withdraw() still take a double parameter.)

In this case, the only calling method potentially affected was Main(), but the effects could have extended to dozens of methods that accessed bank accounts, and those methods could have been spread over hundreds of assemblies. None of those methods would have to change, because the fix was within the confines of the BankAccount class, whose public interface (its public methods) didn't outwardly change. This solution wouldn't have been possible if the internal members of the class had been exposed to external methods.

A static (class) data member may be exposed through a static property, as shown in this simplistic example (note its compact layout):

public class BankAccount
{
  private static int _nextAccountNumber = 1000;
  public static int NextAccountNumber { get { return _nextAccountNumber; } }
  // . . .
}

The NextAccountNumber property is accessed through the class as follows because it isn't an instance property (it's declared static):

// Read the account number property.
int value = BankAccount.NextAccountNumber;

(In this example, value is outside the context of a property, so it isn't a reserved word.)

A get operation can perform extra work other than simply retrieving the associated property, as shown here:

public static int AccountNumber
{
  // Retrieve the property and set it up for the
  // next retrieval by incrementing it.
  get{ return ++_nextAccountNumber; }
}

This property increments the static account number member before returning the result. This action probably isn't a good idea, however, because the user of the property receives no clue that anything is happening other than the actual reading of the property. The incrementation is a side effect.

Most properties described in the previous section are utterly routine, and writing them is tedious (though simple):

private string _name;  // An underlying data member for the property
public string Name { get { return _name; } set { _name = value; } }

Because you write this same boilerplate code repeatedly, the C# 3.0 compiler now does it for you. All you have to write for the previous property (including the private data member) is this line:

public string Name { get; set; }

This line is sort of equivalent to

private string <somename>;  // What's <somename>? Don't know or care.
public string Name { get { return <somename>; } set { <somename> = value; } }

public int AnInt { get; set; } // Compiler provides a private variable.
. . .
AnInt = 2; // Initialize compiler-written instance variable via property.

Accessor properties don't necessarily have to be declared public. You can declare them at any appropriate level, even private, if the accessor is used only inside its class. (The upcoming example marks the Name property internal.)

You can even adjust the access levels of the get and set portions of an accessor individually. Suppose that you don't want to expose the set accessor outside your class — it's for internal use only. You can write the property like this:

internal string Name { get; private set; }

Try out a constructor thingie. Consider the following program, DemonstrateCustomConstructor:

// DemonstrateCustomConstructor -- Demonstrate how you can replace the
//    C# default constructor with your own, custom constructor.
//    Creates a class with a constructor and then steps through a few scenarios.
using System;
namespace DemonstrateCustomConstructor
{
  // MyObject -- Create a class with a noisy custom constructor

//    and an internal data object.
  public class MyObject
  {
    // This data member is a property of the class (it's static).
    private static MyOtherObject _staticObj = new MyOtherObject();
    // This data member is a property of each instance.
    private MyOtherObject _dynamicObj;
    // Constructor (a real chatterbox)
    public MyObject()
    {
      Console.WriteLine("MyObject constructor starting");
      Console.WriteLine("(Static data member constructed before " +
                        "this constructor)");
      Console.WriteLine("Now create nonstatic data member dynamically:");
      _dynamicObj = new MyOtherObject();
      Console.WriteLine("MyObject constructor ending");
    }
  }
  // MyOtherObject -- This class also has a noisy constructor but
  //    no internal members.
  public class MyOtherObject
  {
    public MyOtherObject()
    {
      Console.WriteLine("MyOtherObject constructing");
    }
  }
  public class Program
  {
    public static void Main(string[] args)
    {
      Console.WriteLine("Main() starting");
      Console.WriteLine("Creating a local MyObject in Main():");
      MyObject localObject = new MyObject();
      // Wait for user to acknowledge the results.
      Console.WriteLine("Press Enter to terminate...");
      Console.Read();
    }
  }
}

Executing this program generates the following output:

Main() starting
Creating a local MyObject in Main():
MyOtherObject constructing
MyObject constructor starting
(Static data member constructed before this constructor)
Now create nonstatic data member dynamically:
MyOtherObject constructing
MyObject constructor ending
Press Enter to terminate...

The following steps reconstruct what just happened:

Job well done!

Executing the same program from the debugger is illuminating:

Book IV gives you a thorough tour of the debugger.

Besides letting you initialize data members in a constructor, C# enables you to initialize data members directly by using initializers.

Thus I could have written the BankAccount class as follows:

public class BankAccount
{
  // Bank accounts start at 1000 and increase sequentially.
  private static int _nextAccountNumber = 1000;
  // Maintain the account number and balance for each object.
  private int _accountNumber = ++_nextAccountNumber;
  private double _balance = 0.0;
  // . . . other members . . .
}

Here's the initializer business. Both _accountNumber and _balance are assigned a value as part of their declaration, which has the same effect as a constructor but without having to do the work in it.

Be clear about exactly what's happening. You may think that this statement sets _balance to 0.0 right now. However, _balance exists only as a part of an object. Thus the assignment isn't executed until a BankAccount object is created. In fact, this assignment is executed every time an object is created.

Note that the static data member _nextAccountNumber is initialized the first time the BankAccount class is accessed — as your tour in the debugger showed, that's the first time you access any method or property of the object owning the static data member, including the constructor.

Initializers are executed in the order of their appearance in the class declaration. If C# encounters both initializers and a constructor, the initializers are executed before the body of the constructor.

In the DemonstrateCustomConstructor program, move the call new MyOtherObject() from the MyObject constructor to the declaration itself, as follows (see the bold text), modify the second WriteLine() statement as shown, and then rerun the program:

public class MyObject
{
  // This member is a property of the class (it's static).
  private static MyOtherObject _staticObj = new MyOtherObject();
  // This member is a property of each instance.
  private MyOtherObject _dynamicObj = new MyOtherObject();  // <- Here.
  public MyObject()
  {
    Console.WriteLine("MyObject constructor starting");
    Console.WriteLine(
      "Both data members initialized before this constructor)");
    // _dynamicObj construction was here, now moved up.
    Console.WriteLine("MyObject constructor ending");
  }
}

Compare the following output from this modified program with the output from its predecessor, DemonstrateCustomConstructor:

Main() starting
Creating a local MyObject in Main():
MyOtherObject constructing
MyOtherObject constructing

MyObject constructor starting
(Both data members initialized before this constructor)
MyObject constructor ending
Press Enter to terminate...

Suppose that you have a little class to represent a Student:

public class Student
{
  public string Name { get; set; }
  public string Address { get; set; }
  public double GradePointAverage { get; set; }
}

A Student object has three public properties, Name, Address, and GradePointAverage, which specify the student's basic information.

Normally, when you create a new Student object, you have to initialize its Name, Address, and GradePointAverage properties like this:

Student randal = new Student();
randal.Name = "Randal Sphar";
randal.Address = "123 Elm Street, Truth or Consequences, NM 00000";
randal.GradePointAverage = 3.51;

(Yes, Virginia, there is a Truth or Consequences, New Mexico. My nephew Randal was born there.)

If Student had a constructor, you could do something like this:

Student randal = new Student
  ("Randal Sphar", "123 Elm Street, Truth or Consequences, NM, 00000", 3.51);

Sadly, however, Student lacks a constructor, other than the default one that C# supplies automatically — which takes no parameters.

Student randal = new Student
  { Name = "Randal Sphar",
    Address = "123 Elm Street, Truth or Consequences, NM 00000",
    GradePointAverage = 3.51
  };

The last two examples are different in this respect: The first one, using a constructor, shows parentheses containing two strings and one double value separated by commas, and the second one, using the new object-initializer syntax, has instead curly braces containing three assignments separated by commas. The syntax works something like this:

new LatitudeLongitude
    { assignment to Latitude, assignment to Longitude  };

The new object-initializer syntax lets you assign to any accessible set properties of the LatitudeLongitude object in a code block (the curly braces). The block is designed to initialize the object. Note that you can set only accessible properties this way, not private ones, and you can't call any of the object's methods or do any other work in the initializer.

The new syntax is much more concise: one statement versus three. And, it simplifies the creation of initialized objects that don't let you do so through a constructor. (I broke the Student example into multiple lines only to fit it on the page — and that was only because the name Truth or Consequences is long. If you lived there, it would seem even longer.)

The new object-initializer syntax doesn't gain you much of anything besides convenience, but convenience when you're coding is high on any programmer's list. So is brevity. Besides, the feature becomes essential when you read about anonymous classes.

Look up the term object initializer in Help to find the lawyer-y language stuff concerning which kinds of properties it works with.