Introducing classes

We've seen how variables store information and how methods perform actions, but our programming toolkit is still somewhat limited. We need a way of creating a sort of super container that has its variables and methods that can be referenced from the container itself. Enter classes:

• Conceptually, a class holds related information, actions, and behaviors inside a single container. They can even communicate with each other.
• Technically, classes are data structures. They can contain variables, methods, and other programmatic information, all of which can be referenced when an object of the class is created.
• Practically, a class is a blueprint. It sets out the rules and regulations for any object (called an instance) created using the class blueprint.

You've probably realized that classes surround us not only in Unity but in the real world as well. Next, we'll take a look at the most common Unity class and how they function in the wild.

A common Unity class

Before you wonder what a class looks like in C#, you should know that you've been working with a class this whole chapter. By default, every script created in Unity is a class, which you can see from the class keyword on line 5:

public class LearningCurve: MonoBehavior

MonoBehavior just means that this class can be attached to a GameObject in the Unity scene. In C#, classes can exist on their own, which we'll see when we create standalone classes in Chapter 5, Working with Classes and Object-Oriented Programming.

The terms script and class are sometimes used interchangeably in Unity resources. For consistency, I'll be referring to C# files as scripts if they're attached to GameObjects and as classes if they are standalone. 

Classes are blueprints

For our last example, let's think about a local post office. It's a separate, self-contained environment that has properties, such as a physical address (a variable), and the ability to execute actions, such as sending in your secret decoder ring voucher (methods). 

This makes a post office a great example of a potential class that we can outline in the following block of pseudocode:

PostOffice
{
    // Variables
    Address = "1234 Letter Opener Dr."

    // Methods
    DeliverMail()
    SendMail()
}

The main takeaway here is that when information and behaviors follow a predefined blueprint, complex actions and inter-class communication becomes possible.

For instance, if we had another class that wanted to send a letter through our PostOffice class, it wouldn't have to wonder where to go to fire this action. It could simply call the SendMail function from the PostOffice class, as follows:

PostOffice.SendMail()

Alternatively, you could use it to look up the address of the Post Office so you know where to post your letters:

PostOffice.Address

If you're wondering about the use of periods (called dot notation) between words, we'll be ping into that at the end of the chapter – hold tight.

Your basic programming toolkit is now complete (well, the theory drawer, at least). We'll spend the rest of this section taking you deeper into the syntax and practical uses of variables, methods, and classes.