Classes and Objects

Up to now, our programs have been variables + methods. Data lived in one place; the code that worked on it lived in another.

That works fine for small examples. But as a program grows, the gap between "the data" and "the rules about that data" becomes a real problem. If a BankAccount is "a double balance plus a bunch of rules about how it can change," what stops some unrelated piece of code from just writing balance = -9999 and breaking everything?

The answer is the class — a way to bundle data and the behavior that owns it into a single unit.

A program of just variables and methods

It works. But it represents one account. If we needed two accounts, we'd have to invent balance1, balance2, and a Deposit1, Deposit2... which is ridiculous. We need a way to say "an account is a kind of thing, and I can have as many as I want."

A class is a blueprint

A class describes what every instance of a thing should look like and what it should be able to do.

An object is an actual instance built from that blueprint.

The class is the idea of a bank account. The objects are the actual accounts.

Our first class

Read it carefully:

• public class BankAccount { ... } declares the blueprint.
• Owner and Balance are fields — data that every instance owns its own copy of.
• Deposit and Withdraw are methods that work on this instance's data.
• new BankAccount() creates a fresh object on the heap.
• alice.Deposit(100) runs Deposit on alice — so Balance inside the method refers to alice's Balance, not bob's.

Two objects, two independent balances, one class.

A picture of the heap

alice and bob are references sitting on the stack. The actual objects live on the heap. This is exactly the value-vs- reference picture from the type system chapter.

Constructors: building a valid object

Leaving fields uninitialized after new is a recipe for bugs. A constructor is a special method that runs once, when the object is created, and is the natural place to put initialization.

Now you cannot create a BankAccount without supplying an owner and an opening balance. The class guarantees its own minimum validity.

this: the current object

Inside a method, this refers to "the object the method was called on." You can usually omit it, but it's useful when a parameter has the same name as a field.

Properties: smart fields

Public fields are convenient but expose your internals directly. The idiomatic C# way to expose data is via a property, which looks like a field at the call site but is really a pair of methods — a get and a set — that you can later replace with validation or computed logic without breaking callers.

We'll lean on properties heavily in the next chapter when we add validation.

Multi-file: a class lives in its own file

The customary convention is one public class per file, with the filename matching the class name. Bigger programs naturally grow into many files.

Notice how the entry file reads like a narrative — "open an account, withdraw, deposit, print" — while the rules of being a bank account live in their own file. That separation is the whole game.

Practice

area=12
perimeter=14

Test your understanding