Introduction to OODSA

Why this lesson matters

Welcome to OODSA Algorithmic Thinking. This first lesson sets the mental model for the entire course: before we write clever code, we need a way to understand a problem, name its parts, and design responsibilities.

In this course, we will use OODSA as a practical programming lens: Object-Oriented Design and Analysis applied to algorithmic problem solving.

That means we will ask questions like:

• What are the important objects in this problem?
• What data does each object own?
• What behavior should each object provide?
• How do objects collaborate to solve the task?

Later lessons will focus on algorithmic thinking, data structures, and specific algorithm families. For now, we are building the foundation: how to look at a software problem before rushing into code.

Analysis first, design second

OODSA combines two related activities:

Object-Oriented Analysis

This is about understanding the problem domain.

You identify:

• entities or concepts
• relationships between them
• rules and constraints
• operations the system must support

Object-Oriented Design

This is about shaping that understanding into software.

You decide:

• which classes should exist
• what state each class stores
• what methods each class exposes
• how objects communicate

A simple way to remember it:

Analysis: What does the problem contain?
Design:   How should our program represent it?

Good OODSA does not mean creating lots of classes. It means creating the right boundaries so code is easier to reason about, test, and extend.

Objects bundle data and behavior

An object is not just a container for values. In object-oriented design, an object usually represents a responsible participant in the program.

For example, imagine a bank account:

BankAccount
├── State
│   ├── Owner
│   └── Balance
└── Behavior
    ├── Deposit(amount)
    └── Withdraw(amount)

The key idea is responsibility:

• The account owns its balance.
• The account controls how that balance changes.
• Other code should not freely edit the balance directly.

This is one reason OODSA pairs naturally with algorithmic thinking: once responsibilities are clear, the steps of a solution become easier to organize.

A small object-oriented representation

Here is a compact C# example. Notice that the balance is not changed directly from outside the object. Instead, callers use methods that express meaningful actions.

This is not about banking specifically. It is about the habit of asking: who should own this data, and who should be responsible for changing it?

```csharp
using System;

public class BankAccount
{
    public string Owner { get; }
    public decimal Balance { get; private set; }

    public BankAccount(string owner, decimal startingBalance)
    {
        Owner = owner;
        Balance = startingBalance;
    }

    public void Deposit(decimal amount)
    {
        if (amount <= 0)
        {
            Console.WriteLine("Deposit ignored: amount must be positive.");
            return;
        }

        Balance += amount;
    }

    public bool Withdraw(decimal amount)
    {
        if (amount <= 0 || amount > Balance)
        {
            return false;
        }

        Balance -= amount;
        return true;
    }
}

public class Program
{
    public static void Main()
    {
        BankAccount account = new BankAccount("Maya", 100m);

        account.Deposit(50m);
        bool success = account.Withdraw(30m);

        Console.WriteLine($"Owner: {account.Owner}");
        Console.WriteLine($"Withdrawal successful: {success}");
        Console.WriteLine($"Balance: {account.Balance}");
    }
}
```

Which option best reflects an OODSA-style approach to a programming problem?

A practical OODSA workflow

You can treat OODSA as a repeatable thinking process:

1. Understand the problem
2. Identify nouns and actions
3. Choose candidate objects
4. Assign responsibilities
5. Define relationships
6. Sketch behavior
7. Implement and refine

This process is not perfectly linear. As you code, you often discover that a class has too many responsibilities, a method belongs somewhere else, or a relationship is unclear.

That is normal. OODSA gives you language for improving the design instead of just saying, "this code feels messy."

True or false: In OODSA, the first question is usually "Which advanced algorithm should I use?"

Protecting invariants

An invariant is a rule that should always remain true for an object.

For example, a shopping cart total should not become negative just because outside code edited a field directly. Encapsulation helps protect these rules by keeping state private and exposing controlled methods.

In the example below, the cart controls how items are added and how the total is calculated.

```csharp
using System;
using System.Collections.Generic;

public class ShoppingCart
{
    private readonly List<decimal> prices = new List<decimal>();

    public void AddItem(decimal price)
    {
        if (price <= 0)
        {
            Console.WriteLine("Item not added: price must be positive.");
            return;
        }

        prices.Add(price);
    }

    public decimal GetTotal()
    {
        decimal total = 0m;

        foreach (decimal price in prices)
        {
            total += price;
        }

        return total;
    }
}

public class Program
{
    public static void Main()
    {
        ShoppingCart cart = new ShoppingCart();

        cart.AddItem(12.99m);
        cart.AddItem(5.50m);
        cart.AddItem(-3m);

        Console.WriteLine($"Cart total: {cart.GetTotal()}");
    }
}
```

Fill in the blank:

The object-oriented principle of bundling state with behavior and controlling access to internal details is called ______.

The foundation is set

You now have the core OODSA lens:

• analyze the problem before designing classes
• model important concepts as objects
• assign clear responsibilities
• protect object state through encapsulation
• use design to make code easier to reason about

In the next lesson, Algorithmic Thinking, we will shift from modeling objects to planning step-by-step solutions. The bridge between the two is important: good design helps your algorithms live in code that is understandable, testable, and maintainable.