Chapter 11
Holding a Class Responsible
In This Chapter
ᮣ
Letting the class protect itself through access control
ᮣ
Allowing an object to initialize itself via the constructor
ᮣ
Defining multiple constructors for the same class
ᮣ
Constructing static or class members
A
class must be held responsible for its actions. Just as a microwave
oven shouldn’t burst into flames if you press the wrong key, a class
shouldn’t allow itself to roll over and die when presented with incorrect data.
To be held responsible for its actions, a class must ensure that its initial state
is correct, and control its subsequent state so that it remains valid. C# pro-
vides both of these capabilities.
Restricting Access to Class Members
Simple classes define all their members as
public
. Consider a
BankAccount
program that maintains a
balance
data member to retain the balance in each
account. Making that data member
public
puts everyone on the honor
system.
I don’t know about your bank, but my bank is not nearly so forthcoming as to

leave a pile of money and a register for me to mark down every time I add
money to or take money away from the pile. After all, I may forget to mark my
withdrawals in the register. I’m not as young as I used to be — my memory is
beginning to fade.
Controlling access avoids little mistakes like forgetting to mark a with-
drawal here or there. It also manages to avoid some really big mistakes with
withdrawals.
18_597043 ch11.qxd 9/20/05 2:07 PM Page 221
I know exactly what you functional types out there are thinking: “Just make a
rule that other classes can’t access the
balance
data member directly, and
that’s that.” That approach may work in theory, but in practice it never does.
People start out with good intentions (like my intentions to work out every
day), but those good intentions get crushed under the weight of schedule
pressures to get the product out the door. Speaking of weight. . . .
A public example of public BankAccount
The following example
BankAccount
class declares all its methods
public
but declares its data members, including
nAccountNumber
and
dBalance
, to
be
private
. Note that I’ve left it in an incorrect state to make a point. The fol-
lowing code won’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 OK -
// 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”
+ “\nThe following is supposed to “
+ “generate a compile error”);
ba.dBalance += 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 nNextAccountNumber = 1000;
private int nAccountNumber;
222
Part IV: Object-Oriented Programming
18_597043 ch11.qxd 9/20/05 2:07 PM Page 222
// maintain the balance as a double variable
private double dBalance;
// Init - initialize a bank account with the next
// account id and a balance of 0
public void InitBankAccount()
{
nAccountNumber = ++nNextAccountNumber;
dBalance = 0.0;
}
// GetBalance - return the current balance
public double GetBalance()
{
return dBalance;
}
// AccountNumber
public int GetAccountNumber()
{
return nAccountNumber;
}
public void SetAccountNumber(int nAccountNumber)
{

this.nAccountNumber = nAccountNumber;
}
// Deposit - any positive deposit is allowed
public void Deposit(double dAmount)
{
if (dAmount > 0.0)
{
dBalance += dAmount;
}
}
// Withdraw - you can withdraw any amount up to the
// balance; return the amount withdrawn
public double Withdraw(double dWithdrawal)
{
if (dBalance <= dWithdrawal)
{
dWithdrawal = dBalance;
}
dBalance -= dWithdrawal;
return dWithdrawal;
}
// GetString - return the account data as a string
public string GetString()
{
string s = String.Format(“#{0} = {1:C}”,
GetAccountNumber(),
GetBalance());
return s;
}
}

}
223
Chapter 11: Holding a Class Responsible
18_597043 ch11.qxd 9/20/05 2:07 PM Page 223
In this code,
dBalance -= dWithdrawal
is the same as
dBalance =
dBalance - dWithdrawal
. C# programmers tend to use the shortest nota-
tion available.
Marking a member
public
makes that member available to any other code
within your program.
The
BankAccount
class provides an
InitBankAccount()
method to initial-
ize 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 like “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, I’m sure you’ll agree. However,
everyone’s on the honor system as long as
dBalance
is accessible to external
methods. (In this context, external means “external to the class but within the
same program.”) That 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. Well-written code with rules that the compiler can enforce
saves us all from the occasional bullet to the big toe.
Before you get too excited, however, notice that the program doesn’t build.
Attempts to do so generate the following error message:
‘DoubleBankAccount.BankAccount.dBalance’ 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,” but that’s essentially what it means. The statement
ba.dBalance += 10;
is illegal because
dBalance
is not accessible to
Main()
, a function 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()

.
The default access type is
private
. Forgetting to declare a member specifi-
cally is the same as declaring it
private
. However, you should include the
private
keyword to remove any doubt. Good programmers make their inten-
tions explicit, which is another way to reduce errors.
Jumping ahead — other levels of security
This section depends on some knowledge of inheritance (Chapter 12) and
namespaces (Bonus Chapter 2 on the CD). You can skip it for now if you want
but just know that it’s here when you need it.
C# provides the following levels of security:
224
Part IV: Object-Oriented Programming
18_597043 ch11.qxd 9/20/05 2:07 PM Page 224
ߜ A
public
member is accessible to any class in the program.
ߜ A
private
member is accessible only from the current class.
ߜ A
protected
member is accessible from the current class and any of its
subclasses. See Chapter 12.
ߜ An
internal

member is accessible from any class within the same pro-
gram module or assembly.
A C# module or “assembly” is a separately compiled piece of code, either
an executable program in an
.EXE
file or a supporting library module in
a
.DLL
file. A single namespace can extend across multiple modules.
Bonus Chapter 5 on the CD explains C# assemblies. Bonus Chapter 2
explains namespaces.
ߜ An
internal protected
member is accessible from the current class
and any subclass and from classes within the same module.
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 nice, comfortable level of security.
Why Worry about Access Control?
Declaring the internal members of a class
public
is a bad idea for at least
these reasons:
ߜ With all data members
public

, you can’t easily determine when and
how data members are getting modified. Why bother building safety
checks into the
Deposit()
and
Withdraw()
methods? In fact, why
bother with these methods at all? Any method of any class can modify
these elements at any time. If other functions can access these data
members, they almost certainly will. (Bang! You just shot yourself in the
foot.)
Your
BankAccount
program may execute for an hour or so before you
notice that one of the accounts has a negative balance. The
Withdraw()
method would have made sure this didn’t happen. Obviously, some
other function accessed the balance without going through
Withdraw()
.
Figuring out which function is responsible and under what conditions is
a difficult problem.
ߜ Exposing all the data members of the class makes the interface too
complicated. As a programmer using the
BankAccount
class, you don’t
want to know about the internals of the class. You just need to know that
you can deposit and withdraw funds. It’s like a candy machine with fifty
buttons versus one with just a few buttons.
225

Chapter 11: Holding a Class Responsible
18_597043 ch11.qxd 9/20/05 2:07 PM Page 225
ߜ Exposing internal elements leads to a distribution of the class rules.
For example, my
BankAccount
class does not allow the balance to go
negative under any circumstances. That’s a business rule that should be
isolated within the
Withdraw()
method. Otherwise, you have to add
this check everywhere the balance is updated.
What happens when the bank decides to change the rules so that
“valued customers” are allowed to carry a slightly negative balance for a
short period to avoid unintended overdrafts? You now have to search
through the program to update every section of code that accesses the
balance to make sure that the safety checks — not the bank checks —
are changed.
Don’t make your classes and methods any more accessible than necessary.
This isn’t so much paranoia about snoopy hackers as a prudent step that
helps reduce errors as you code. Use
private
if possible, and then escalate
to
protected
,
internal
,
internal protected
, or
public

as necessary.
Accessor methods
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 the contents are
inaccessible. In addition, using the “Render unto Caesar” policy, the class
should have the right to decide how it gets displayed.
In addition, you see one “getting” method,
GetBalance()
, and a set of “set-
ting” methods,
GetAccountNumber()
and
SetAccountNumber()
. You may
wonder why I would bother to declare a data member like
dBalance private
but provide a
GetBalance()

method to return its value. I actually have two
reasons, as follows:
ߜ
GetBalance()
does not provide a way to modify
dBalance
— it
merely returns its value. This makes the balance read-only. To use the
analogy of an actual bank, you can look at your balance any time you
want; you just can’t take money out of your account without going
through the bank’s withdrawal mechanism.
ߜ
GetBalance()
hides the internal format of the class from external
methods.
GetBalance()
may go through an extensive calculation, read-
ing receipts, adding account charges, and accounting for anything else
your bank may want to subtract from your balance. External functions
don’t know and don’t care. Of course, you care what fees are being
charged. You just can’t do anything about them, short of changing
banks.
226
Part IV: Object-Oriented Programming
18_597043 ch11.qxd 9/20/05 2:07 PM Page 226
Finally,
GetBalance()
provides a mechanism for making internal changes to
the class without the need to change the users of
BankAccount

. If the FDIC
mandates that your bank store deposits differently, that shouldn’t change the
way you access your account.
Access control to the rescue — an example
The following
DoubleBankAccount
program demonstrates a potential flaw in
the
BankAccount
program. The entire program is on your CD; 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)
namespace DoubleBankAccount
{
using System;
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 dDeposit = 123.454;
Console.WriteLine(“Depositing {0:C}”, dDeposit);
ba.Deposit(dDeposit);
// account balance
Console.WriteLine(“Account = {0}”, ba.GetString());
// here’s the problem
double dAddition = 0.002;
Console.WriteLine(“Adding {0:C}”, dAddition);
ba.Deposit(dAddition);
// resulting balance
Console.WriteLine(“Resulting account = {0}”, ba.GetString());
// wait for user to acknowledge the results
Console.WriteLine(“Press Enter to terminate...”);
Console.Read();
}
}
227
Chapter 11: Holding a Class Responsible
18_597043 ch11.qxd 9/20/05 2:07 PM Page 227
The
Main()
function 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 as follows:
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 account 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 cents that everything balances out in the
long run.
The easiest way to do this is by converting the bank accounts to
decimal
and using the
Decimal.Round()
method, as shown in the following
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 dDeposit = 123.454;
Console.WriteLine(“Depositing {0:C}”, dDeposit);
ba.Deposit(dDeposit);
// account balance
Console.WriteLine(“Account = {0}”, ba.GetString());
// now add in a very small amount
double dAddition = 0.002;
Console.WriteLine(“Adding {0:C}”, dAddition);
ba.Deposit(dAddition);
228
Part IV: Object-Oriented Programming
18_597043 ch11.qxd 9/20/05 2:07 PM Page 228
// 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 nNextAccountNumber = 1000;
private int nAccountNumber;
// maintain the balance as a single decimal variable

private decimal mBalance;
// Init - initialize a bank account with the next
// account id and a balance of 0
public void InitBankAccount()
{
nAccountNumber = ++nNextAccountNumber;
mBalance = 0;
}
// GetBalance - return the current balance
public double GetBalance()
{
return (double)mBalance;
}
// AccountNumber
public int GetAccountNumber()
{
return nAccountNumber;
}
public void SetAccountNumber(int nAccountNumber)
{
this.nAccountNumber = nAccountNumber;
}
// Deposit - any positive deposit is allowed
public void Deposit(double dAmount)
{
if (dAmount > 0.0)
{
// round off the double to the nearest cent before depositing
decimal mTemp = (decimal)dAmount;
mTemp = Decimal.Round(mTemp, 2);

mBalance += mTemp;
}
}
// Withdraw - you can withdraw any amount up to the
// balance; return the amount withdrawn
public decimal Withdraw(decimal dWithdrawal)
{
if (mBalance <= dWithdrawal)
{
dWithdrawal = mBalance;
}
229
Chapter 11: Holding a Class Responsible
18_597043 ch11.qxd 9/20/05 2:07 PM Page 229
mBalance -= dWithdrawal;
return dWithdrawal;
}
// 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 the 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()
function 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...
So what?
You could argue that I should have written the
BankAccount
program using
decimal
input arguments to begin with, and I would probably 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 with no changes to the application software. (Notice that
the class’s public interface didn’t change:

Balance()
still returns a
double
.)
I repeat: Applications using class
BankAccount
didn’t have to change.
In this case, the only function potentially affected was
Main()
, but the effects
could have extended to dozens of functions that accessed bank accounts,
and those functions could have been spread over hundreds of modules. None
of those functions would have to change because the fix was within the con-
fines of the
BankAccount
class. This would not have been possible if the
internal members of the class had been exposed to external functions.
Internal changes to a class still require some retesting of other code, even
though you didn’t have to modify that code.
230
Part IV: Object-Oriented Programming
18_597043 ch11.qxd 9/20/05 2:07 PM Page 230
Defining class properties
The
GetX()
and
SetX()
methods demonstrated in the
BankAccount
pro-

grams are called access functions, or simply accessors. Although they signify
good programming habits in theory, access functions can get clumsy in prac-
tice. For example, the following code is necessary to increment
nAccountNumber
by 1:
SetAccountNumber(GetAccountNumber() + 1);
C# defines a construct called a property, which makes using access functions
much easier. The following code snippet defines a read-write property,
AccountNumber
:
public int AccountNumber // no parentheses here
{
get{return nAccountNumber;} // curly braces & semicolon
set{nAccountNumber = value;} // value is a keyword
}
The
get
section is implemented whenever the property is read, while the
set
section is invoked on the write. The following
Balance
property is read-only
because only the
get
section is defined:
public double Balance
{
get
{
return (double)mBalance;

}
}
In use, these properties appear as follows:
BankAccount ba = new BankAccount();
// set the account number property
ba.AccountNumber = 1001;
// read both properties
Console.WriteLine(“#{0} = {1:C}”, ba.AccountNumber, ba.Balance);
The properties
AccountNumber
and
Balance
look very much like
public
data members, both in appearance and in use. However, properties enable
the class to protect internal members (
Balance
is a read-only property)
and hide their implementation (the underlying
mBalance
data member is
private
). Notice that
Balance
performs a conversion — it could have per-
formed any number of calculations. Properties aren’t necessarily one-liners.
By convention, the names of properties begin with a capital letter. Note that
properties don’t have parentheses:
Balance
, not

Balance()
.
231
Chapter 11: Holding a Class Responsible
18_597043 ch11.qxd 9/20/05 2:07 PM Page 231
Properties are not necessarily inefficient. The C# compiler can optimize a
simple accessor to the point that it generates no more machine code than
accessing the data member directly. This is important, not only to an applica-
tion program but also to C# itself. The C# library uses properties throughout,
and you should, too, even to access class data members from methods in the
same class.
Static properties
A static (class) data member may be exposed through a static property, as
shown in the following simplistic example:
public class BankAccount
{
private static int nNextAccountNumber = 1000;
public static int NextAccountNumber
{
get{return nNextAccountNumber;}
}
// . . .
}
The
NextAccountNumber
property is accessed through the class as follows,
because it isn’t a property of a single object:
// read the account number property
int nValue = BankAccount.NextAccountNumber;
Properties with side effects

A
get
operation can perform extra work other than simply retrieving the
associated property, as shown in the following code:
public static int AccountNumber
{
// retrieve the property and set it up for the
// next retrieval by incrementing it
get{return ++nNextAccountNumber;}
}
This property increments the static account number member before return-
ing the result. This probably is not a good idea, however, because the user of
the property gets no clue that anything is happening other than the actual
reading of the property. The incrementation is a side effect.
Like the accessor functions that they mimic, properties should not change
the state of the class other than, say, setting a data member’s value. In gen-
eral, both properties and methods should avoid side effects because they can
lead to subtle bugs. Change a class as directly and explicitly as possible.
232
Part IV: Object-Oriented Programming
18_597043 ch11.qxd 9/20/05 2:07 PM Page 232