1.2.9 Defining Classes

A Class Definition Creates a New Kind of Object

Earlier, you worked with objects and learned that a class describes the structure shared by objects of the same kind.

In C#, you define that structure with a class declaration.

For example:

public class Player
{
}

This tells C# that the program has a class named Player.

Read the Class Declaration from Left to Right

Consider:

public class Player
{
}

The important parts are:

The class body is where the class's fields and later its methods are defined.

Use a Class Name That Describes One Kind of Thing

Class names should communicate what kind of object the class represents.

Soccer examples might include:

Player
Team
Match
Ball

Each name represents one general kind of thing rather than one particular object.

For example, Player is the class name. A later object such as player1 is one instance of that class.

Class Names Use PascalCase

In the course examples, class names use PascalCase.

That means each word begins with an uppercase letter:

Player
SoccerBall
MatchOfficial

A name such as:

soccerBall

does not follow that class-name convention.

The Class Body Defines the Structure

An empty class is valid as a starting point:

public class Player
{
}

But an empty class does not yet describe much about a soccer player.

As the design develops, fields are added inside the braces so Player objects can store the information required by the model.

The next page focuses specifically on defining those fields.

One Class Definition Can Support Many Objects

You define the class once:

public class Player
{
}

Later, the program can create multiple Player objects from that same class design.

The class defines the shared structure. Each object has its own identity and state.

Keep One Focused Class in Each Source File

When the course asks you to define a class, create the class that matches the current design and keep the source organized around that class.

For example, a file named:

Player.cs

should contain the Player class used by the current solution.

This makes the source easier to navigate and keeps the class name, file name, and model easy to connect.

Comments Should Explain Purpose, Not Repeat Syntax

When a comment is required, use it to clarify why a class exists or what role it plays.

A weak comment merely repeats the code:

// This is the Player class.
public class Player
{
}

A more useful comment would explain the class's role in the current program:

// Represents a soccer player tracked by the application.
public class Player
{
}

Comments should add meaning rather than narrate syntax that is already obvious.

Connect the C# Class to the UML Class

A UML class diagram might identify a class named:

Player

The C# class declaration should use the same intended class identity:

public class Player
{
}

The UML model communicates the design. The C# source defines that design in executable source code.

The Core Pattern

For now, the essential class-definition pattern is:

public class ClassName
{
}

When you read or write one, ask: