A Shift in Thinking – Intro to OOP

Object-Oriented Programming (OOP) is a programming paradigm, or a way of thinking about and structuring your code. Instead of just a long list of procedures, OOP encourages us to model things from the real world (or from a problem domain) as self-contained "objects."

Each object elegantly bundles together two things:

• Data (State): Information that describes the object. For a User object, this might be their username, email, and level.
• Behavior (Methods): Actions that the object can perform. A User object might be able to Login(), Logout(), or ChangePassword().

This approach of combining data and the methods that operate on that data into a single unit is the cornerstone of OOP. It helps us create code that is more organized, modular, reusable, and easier to reason about as applications grow in complexity.

In the upcoming lessons, we'll explore the core pillars that make OOP so powerful:

• Encapsulation: Protecting an object's internal data and exposing controlled ways to interact with it.
• Inheritance: Allowing a new class to take on the properties and methods of an existing class.
• Polymorphism: Allowing objects of different classes to be treated through a common interface.
• Abstraction: Hiding complex implementation details and showing only the necessary features of an object.

For now, don't worry about memorizing these pillars. Just know that everything starts with the ability to define a class and create objects from it. This is how virtually all modern C# applications and professional test automation frameworks are built.

The Class – Your Code's Blueprint

A class is the template, the blueprint, the cookie cutter. It defines the structure and behavior for a type of object. It doesn't represent a specific user or a specific calculator; instead, it defines what any user or calculator will have and what it can do.

The basic syntax for a class in C# looks like this:

public class ClassName
{
    // Members go here:
    // 1. Fields (to store data)
    // 2. Properties (to control access to data)
    // 3. Methods (to define actions)
}   

Let's create a simple blueprint for a UserAccount object:

// A class to represent a user account
public class UserAccount
{
    // Fields: Private variables that store the object's internal state.
    // The underscore prefix is a common naming convention for private fields.
    private string _passwordHash;
 
    // Properties: Public "gates" that control access to the object's data.
    // They look like fields but have 'get' and 'set' logic.
    public string Username { get; set; }
    public int BonusPoints { get; private set; } // Can be read from outside, but only set from inside this class
    public bool IsActive { get; set; }
 
    // Methods: Actions the object can perform.
    public void GrantBonusPoints(int points)
    {
        if (IsActive)
        {
            BonusPoints += points; // Increment the BonusPoints property
            Console.WriteLine($"{Username} was granted {points} points! You have {BonusPoints} points in your balance now!");
        }
    }
 
    public void DeactivateAccount()
    {
        IsActive = false;
        Console.WriteLine($"Account for {Username} has been deactivated.");
    }
}   

This UserAccount class defines that any user account object we create will have a Username, BonusPoints, and IsActive status, and will be able to perform actions like GrantBonusPoints and DeactivateAccount.

The Object – Bringing Your Blueprint to Life

A class on its own doesn't do much; it's just a plan. To actually use it, you need to create an object. An object is a concrete instance of a class. It's the actual cookie you made from the cutter, the specific car built from the factory mold.

You create an object (a process called instantiation) using the new keyword. This allocates memory for a new object based on the class blueprint.

// Creating an instance of our UserAccount class
UserAccount testUser1 = new UserAccount();
 
// We can create another, completely separate instance
UserAccount testUser2 = new UserAccount();    

Here, testUser1 and testUser2 are variables that hold a reference to two separate UserAccount objects in memory. Even though they were created from the same blueprint, they are distinct entities. Changing one will not affect the other.

This ability to create multiple distinct objects from a single class template is a cornerstone of Object-Oriented Programming.

Using Your Objects – Accessing Members

Once you have an object, you can interact with its public members (its properties and methods) using dot notation (.).

Let's take our testUser1 object and work with it:

// Create an instance
UserAccount testUser1 = new UserAccount();
 
// Set its public properties using dot notation
testUser1.Username = "AutomationAce";
testUser1.IsActive = true;
 
// We can't set the BonusPoints directly from outside because its 'set' is private!
// It can only be changed by methods within the class, like GrantBonusPoints.
// Call its public methods using dot notation
testUser1.GrantBonusPoints(50); // This will change the internal BonusPoints property
 
// We can also get the values of public properties
string currentUsername = testUser1.Username;
int currentBalance = testUser1.BonusPoints;
 
Console.WriteLine($"User '{currentUsername}' has {currentBalance} points.");
// Output: User 'AutomationAce' has 50 points.    

This concept should feel familiar! You've already been doing this when you wrote Console.WriteLine(). You were accessing the WriteLine method on the Console class, or when you wrote message.Length, you were accessing the Length property of a string object.

Constructors – Bringing Objects to Life

When you create a new object using the new keyword, a special method called a constructor is automatically run. Its job is to initialize the new object, setting its initial state and performing any necessary setup tasks.

A constructor looks like a method, but it has two special rules:

1. It has the exact same name as the class.
2. It has no return type (not even void).

If you don't define any constructor yourself, C# provides a default, parameterless one for you behind the scenes (which is what we used when we wrote new UserAccount()).

However, we can define our own constructor to make object creation more convenient, especially for setting initial values.

public class UserAccount
{
    // Properties
    public string Username { get; set; }
    public int BonusPoints { get; private set; }
    public bool IsActive { get; set; }
 
    // This is a constructor that takes parameters
    public UserAccount(string username, int initialBonusPoints)
    {
        Console.WriteLine("A new UserAccount object is being created!");
        Username = username;
        BonusPoints = initialBonusPoints;
        IsActive = true; // Let's default new accounts to active
    }
 
    // ... other methods ...
}   

Now, we can create a fully initialized object in one line:

// Create a new user by calling our custom constructor
UserAccount adminUser = new UserAccount("AdminUser", 99);
 
Console.WriteLine(adminUser.Username); // Output: AdminUser
Console.WriteLine(adminUser.BonusPoints);    // Output: 99    

Constructors ensure that your objects start in a valid and predictable state. While this is a great start, the world of constructors is richer than this single example.

In future lessons, as our classes become more complex, we will explore more advanced topics like having multiple constructors for a single class (constructor overloading) and even more specialized types like private, static, and primary constructors to handle different object creation scenarios. For now, mastering this basic form is the perfect foundation.

The this Keyword – Referring to "Myself"

Sometimes inside a class, particularly in a constructor, you might have a parameter name that is the same as a field or property name. This can be confusing. How does C# know which one you're talking about?

The this keyword solves this. Inside a class's methods or constructor, this refers to the current instance of the object itself.

It's most commonly used to distinguish between a class member (like a field or property) and a parameter with the same name:

public class UserAccount
{
    // Field to store the username
    private string username;
 
    // Constructor
    public UserAccount(string username) // Parameter is also named 'username'
    {
        // 'this.username' refers to the class's field.
        // 'username' refers to the method's parameter.
        this.username = username;
    }
}   

Using this.username = username; explicitly says, "Set the field belonging to *this* object equal to the value of the parameter that was passed into me." It removes all ambiguity. While not always strictly necessary if the names are different, it's a common and good practice for clarity.