We Reinvented OOP by Making a Sandwich (Before Writing Any Code)

A weak developer stares at an empty .cs file and starts typing syntax until the red squiggly lines go away.

A software engineer designs the system before touching a compiler.

Most programming tutorials rush straight into syntax:

"Here is an int. Here is a for loop. Here is public static void Main. Good luck!"

The result? Beginners hit tutorial hell. The second they face a blank screen, their brain locks up. They know the keywords, but they don't know how to decompose a problem.

Inside our engineering mentorship program (BY MY SELF), we ran an experiment with an apprentice named John: Build the entire conceptual foundation of Object-Oriented Programming (OOP) without writing a single line of C# first.

Here is the step-by-step breakdown of how it unfolded—and how it will sharpen your problem-solving skills.

---

1. The Sandwich Challenge: Computers Have Zero Context

To a human, "Make me a cup of coffee" is simple. Your brain automatically fills in the gaps: find a mug, boil water, add grounds, pour.

A computer doesn't know what "make" is. It doesn't know what "coffee" is. It has zero implied context.

We gave our apprentice his first challenge:

The Challenge:
You are programming an autonomous robot with zero real-world knowledge.
It has: Bread, Butter, a Knife, a Plate, and Cheese.
Write an algorithm that gives step-by-step instructions to assemble a cheese sandwich.

Here was his first attempt:

1. Name the items:
   A = Bread, B = Butter, C = Knife, D = Plate, E = Cheese
2. Place A on D
3. Using C take B = F
4. Then F is placed on A
5. E is placed on F
6. A + B + E = G
7. G + D = result
8. result = Sandwich

It looks reasonable to a human. But let's run an engineering audit on it.

2. Debugging Human Logic

When we reviewed the algorithm like a senior engineer reviewing a Pull Request, three major bugs surfaced:
🐛 Bug 1 : Undefined Verbs ("Take")
Using C take B = F
What does "take" mean to a mechanical robot actuator? Does it slice the butter? Scoop it? Stab the block? At what angle? How many grams?
Engineering Rule: Ambiguity in requirements creates defects in production.
🐛 Bug 2 : Commutativity Fallacy
A + B + E = G (Bread + Butter + Cheese = Sandwich)
In algebra, addition is commutative:
A + B == B + A
Does physical assembly work that way? No!
If you put butter under the bread, you get a greasy plate and a structural catastrophe. You cannot use mathematical operators to hide unstated physical actions.
🐛 Bug 3 : Container Leak
G + D = result (where D = Plate)
If you eat the sandwich, do you eat the plate?
The plate is an execution environment / container (like memory allocation).
The sandwich is the data payload. Conflating your data with your runtime infrastructure leads to memory leaks and dirty architecture.

3. Inventing a Mini-Language: The Birth of "State"

For attempt #2, the apprentice separated ingredients from tools and containers, defining operational verbs:

• Entities: Bread, Butter, Cheese
• Tools: Knife
• Container: Plate
• Operations:
• SCOOP: Engage knife at an angle to collect butter.
• SPREAD: Distribute scooped material evenly over a surface.
• LAY: Place an entity onto a base. Then he wrote: SPREAD(Butter, Bread) -> Stack 1 Look closely at what happened here. When butter is spread onto bread, the bread doesn't vanish into a completely new element. The bread simply undergoes a state transition: [ Bread (Plain) ] ── SPREAD(Butter) ──> [ Bread (Buttered) ] This is one of the most critical ideas in computer science:

State is the condition or configuration of an entity at a specific 
point in time. Actions don't just "do things"—they trigger state 
transitions.

4. The Bank Test: Command-Query Separation

To ensure this model wasn't just about physical objects, we tested it against pure information: a Bank Account.
Given an account with Balance = $5,000 and Status = Active, we analyzed four operations:

DEPOSIT($1,000)
WITHDRAW($500)
CHECK_BALANCE()
CLOSE_ACCOUNT()
When looking at CHECK_BALANCE(), the apprentice noticed something crucial:
State Before: Balance = $4,500
Action: CHECK_BALANCE()
State After: Balance = $4,500 (Unchanged!)
Output: $4,500

He had just independently discovered Command-Query Separation (CQS):

OPERATIONS
                        │
         ┌──────────────┴──────────────┐
         ↓                             ↓
     COMMANDS                       QUERIES
   (Mutations)                  (Observations)
   - Change State                - Read State
   - Produce Side Effects        - Zero Side Effects
   - e.g., WITHDRAW()            - e.g., CHECK_BALANCE()

An action doesn't always mutate an entity. Some actions simply inspect and return data.

5. The 100-Cars Dilemma: Why Classes Exist

Finally, we hit him with a scalability problem:

"Imagine you're building a racing simulation. A car has Speed, Fuel, and an Engine. It can Accelerate(), Brake(), and Refuel(). Now imagine you need 100 cars on the track. How do you design this without writing Accelerate() 100 separate times?"
His response:

"You create a single car template.
The template defines what every car HAS and what every car DOES.
Then you stamp out 100 individual cars from that template, 
each holding its own numbers."

Without reading a single programming textbook, he had just defined the relationship between a Class and an Object Instance

CAR CLASS (The Blueprint)
                 ┌───────────────────────────┐
                 │ State:                    │
                 │   Speed, Fuel, Engine     │
                 │ Behavior:                 │
                 │   Accelerate(), Brake()   │
                 └─────────────┬─────────────┘
                               │
                      Instantiate with `new`
                               │
         ┌─────────────────────┴─────────────────────┐
         ↓                                           ↓
     car1 (Object)                               car2 (Object)
  ┌─────────────────┐                         ┌─────────────────┐
  │ Speed = 120 km/h│                         │ Speed = 0 km/h  │
  │ Fuel  = 30 L    │                         │ Fuel  = 80 L    │
  └─────────────────┘                         └─────────────────┘

6. The Rosetta Stone: From Mental Model to C

Here is how our apprentice's first-principles thinking maps directly to professional C#:

Conceptual Model     │Software Engineering     │C# Syntax
                        │Concept                │
Car Template            │Class                    │public class Car 
                        │                       │{ ... }
Individual Stamped Car  │Instance / Object    │Car car1 = new 
                        │                       │Car(0, 50);
Speed, Fuel, Status │Properties / Fields  │public double Speed 
                        │                       │{ get; set; }
Accelerate, Brake   │Methods (Behaviors)  │public void 
                        │                       │Accelerate(double 
                        │                       │amount)
Input Value (20 km/h)   │Parameters / Arguments   │(double amount)
Car(speed, fuel)       │Constructor           │public Car(double 
                        │                       │speed, double fuel)   
                        │                       │
Query (CheckSpeed)  │Return Value         │return this.Speed;

Now look at that exact model written in clean, idiomatic C#:

public class Car
{
    // Properties (State)
    public double Speed { get; private set; }
    public double Fuel { get; private set; }
    public bool IsEngineRunning { get; private set; }

    // Constructor: Defining initial state upon creation
    public Car(double initialSpeed, double initialFuel)
    {
        Speed = initialSpeed;
        Fuel = initialFuel;
        IsEngineRunning = false;
    }

    // Command (State Mutation with Business Logic)
    public void Accelerate(double amount)
    {
        // Guard clause: Cannot accelerate if the engine is off!
        if (!IsEngineRunning) return;

        Speed += amount;
    }

    // Command
    public void StartEngine()
    {
        IsEngineRunning = true;
    }

    // Query (State Observation)
    public double CheckSpeed()
    {
        return Speed;
    }
}

Notice the guard clause
if (!IsEngineRunning) return;

The Takeaway

Syntax is just typing. AI tools and IDE autocompletion can generate syntax for you in seconds.
Engineering is the architecture of thought.
Before you write your next class, method, or function, step away from the keyboard and ask:

1. What are the core Entities?
2. What is their State at any point in time?
3. Is this method a Command (mutating state) or a Query (reading state)?
4. What rules prevent this entity from entering an invalid state? 💬 Discussion Question for the Comments

Next up in our curriculum is Memory & Variables:
If we run:
code

C#
double speed = 100;
speed = speed + 20;

What physically happens to the previous value of 100 in memory?

How would you explain variables and assignment to a complete beginner without using the word "variable"?
Drop your best explanations below! 👇
Now look at that exact model written in clean, idiomatic C#: