The World Is Objects (You Just Haven't Noticed Yet)

Complete Guide | Lesson 1: Pseudocode → Lesson 2: The World Is Objects → Lesson 3: First Principles (Apr 9)

You already think in objects. You just don't know it yet.

Right now, look around whatever room you're in. Every single thing you see is an object. Your phone. Your coffee mug. The chair you're sitting in. The lamp. The window. Each one has characteristics you could describe (color, size, weight, material) and things it can do (the lamp turns on, the phone rings, the chair supports weight).

Congratulations. You just did object-oriented programming in your head. Everything else in this lesson is just learning the vocabulary for what your brain already does naturally.

This is Lesson 2 of the Developer's Tree of Knowledge, and it maps to Ain Soph Aur on the Tree of Life. Ain Soph Aur means "limitless light." It's the first emanation of form from the void. In Lesson 1, we were in the darkness of pure logic, working with pseudocode and Boolean conditions. Now the light turns on, and we can see shapes. We can see things. Objects. And once you learn to see them, you can model any system in the world.

The Grammar of Programming

Here's something that will change how you read English forever: every sentence you've ever spoken contains objects, properties, and methods. Your language teachers called them nouns, adjectives, and verbs. Programmers call them the same thing, just with different labels.

Take this sentence: "The red car drives fast down the highway."

A programmer reads that as:

• Object: Car
• Properties: color = red, speed = fast
• Method: drive()
• Parameter: highway

The car is the thing. Red and fast describe the thing. Driving is what the thing does. The highway is what it does it with.

Now try this one: "The barista grinds fresh beans and pours steamed milk into a ceramic cup."

• Objects: Barista, Beans, Milk, Cup
• Properties: Beans.freshness = fresh, Milk.state = steamed, Cup.material = ceramic
• Methods: Barista.grind(beans), Barista.pour(milk, cup)

You just modeled a Starbucks transaction. That's object-oriented thinking. You've been doing it since you learned to talk. Programming just makes it explicit.

Parse the World Around You

Let's practice. Here are five everyday sentences. For each one, identify the objects, properties, and methods:

1. "The old dog slowly fetches the tennis ball from the muddy yard."

   • Objects: Dog, TennisBall, Yard
   • Properties: Dog.age = old, Dog.speed = slow, Yard.condition = muddy
   • Methods: Dog.fetch(tennisBall, yard)

2. "The student submits the completed assignment to the online portal before midnight."

   • Objects: Student, Assignment, Portal
   • Properties: Assignment.status = completed, Portal.type = online
   • Methods: Student.submit(assignment, portal), with constraint: deadline = midnight

3. "The thermostat detects the room temperature is below 68 degrees and activates the heater."

   • Objects: Thermostat, Room, Heater
   • Properties: Room.temperature = current reading, Thermostat.target = 68
   • Methods: Thermostat.detect(room.temperature), Heater.activate()

Notice something? Sentence 3 contains an IF statement hiding in plain English. "Is below 68 degrees" is a condition. "Activates the heater" is what happens when the condition is true. The pseudocode from Lesson 1 and the object modeling from this lesson aren't separate skills. They're two lenses on the same reality.

Model a Coffee Shop

Let's build something real. Not with code, not yet, but with our brains. We're going to model an entire coffee shop as a system of interacting objects.

Walk into any coffee shop. What do you see?

People: Customers, baristas, maybe a manager. Each is a type of Person, but with different roles and different behaviors.

Things: The espresso machine, the cash register, cups, lids, coffee beans, milk, pastries, menus.

Concepts: An order, a receipt, a menu item, a price, a queue.

All of these are objects. Let's define the important ones:

1OBJECT: Customer
2  Properties: name, wallet (money), currentOrder
3  Methods: browseMenu(), placeOrder(), pay(), tip()
4
5OBJECT: Barista
6  Properties: name, shift, skillLevel
7  Methods: takeOrder(), makeDrink(), callOutName()
8
9OBJECT: CoffeeMachine
10  Properties: waterLevel, beanHopper, temperature, isOn
11  Methods: brew(), steam(), clean(), refill()
12
13OBJECT: Order
14  Properties: items[], customer, total, status
15  Methods: addItem(), removeItem(), calculateTotal()
16
17OBJECT: MenuItem
18  Properties: name, price, size, category, ingredients[]
19  Methods: getDescription(), isAvailable()
20
21OBJECT: Receipt
22  Properties: orderDetails, total, tax, paymentMethod, timestamp
23  Methods: print(), emailTo()

Now here's where it gets interesting: these objects don't exist in isolation. They interact. And those interactions are the entire point of object-oriented design.

Objects Sending Messages

Here's the sequence of what happens when you order a latte:

11. Customer browses Menu (reads MenuItem objects)
22. Customer creates an Order
33. Customer adds MenuItem("Latte", large) to Order
44. Customer gives Order to Barista
55. Barista reads Order
66. Barista tells CoffeeMachine to brew(espresso)
77. Barista tells CoffeeMachine to steam(milk)
88. Barista combines espresso + steamed milk into Cup
99. Barista updates Order.status = "complete"
1010. Barista calls out Customer.name
1111. Customer receives Cup
1212. Customer pays (Order.total)
1313. System generates Receipt

This is a sequence of messages between objects. The Customer doesn't know how the CoffeeMachine works. The CoffeeMachine doesn't know what a Customer is. They interact through the Barista, who acts as an intermediary. Each object does its own job and communicates through well-defined interfaces.

That last point is critical and will come up repeatedly in this series. In Lesson 6, we'll formalize those "well-defined interfaces." In Lesson 7, we'll talk about why the CoffeeMachine not knowing about the Customer is actually a design principle called loose coupling. But for now, just see the pattern: objects have responsibilities, and they communicate through messages.

Thinking Visually: UML-Lite

You don't need to learn the full Unified Modeling Language (UML). UML has 14 diagram types, and most professional developers use about 3 of them. Here are the only three you need right now:

1. The Class Diagram (What Things Are)

A box with three sections: name at the top, properties in the middle, methods at the bottom.

1┌──────────────────┐
2│     Customer      │
3├──────────────────┤
4│ name: String      │
5│ wallet: Money     │
6│ currentOrder: Order│
7├──────────────────┤
8│ browseMenu()     │
9│ placeOrder()     │
10│ pay()            │
11└──────────────────┘

Draw one box per object. Connect them with lines showing relationships:

• Solid line with arrow: "uses" or "knows about"
• Diamond: "contains" or "has a" (Customer has an Order)
• Triangle: "is a type of" (we'll get deep into this in Lesson 5)

2. The Sequence Diagram (How Things Interact)

Vertical lines for each object. Horizontal arrows for messages. Time flows down.

1Customer    Barista    CoffeeMachine
2   |           |            |
3   |--order--->|            |
4   |           |---brew---->|
5   |           |<--coffee---|
6   |           |---steam--->|
7   |           |<--milk-----|
8   |<--latte---|            |
9   |---pay---->|            |

This shows you the flow of a transaction. Who talks to whom, in what order.

3. Simple Relationship Lines

For now, just two:

• "Has a" (solid line with filled diamond): Customer ◆─── Order (a customer HAS an order)
• "Is a" (solid line with open triangle): more on this in Lesson 5 when we cover inheritance

"The purpose of software engineering is to control complexity, not to create it." This principle, from Grady Booch (one of the creators of UML), is why we model before we code. A diagram that reveals complexity is infinitely more useful than code that hides it.

Your Turn: Model Three Systems

Here are three exercises. Do them on paper with boxes and arrows. No code. No computer. Just thinking.

Exercise 1: The Library Model a library system. What are the objects? (Think: Book, Member, Librarian, Shelf, LoanRecord, Fine.) What are their properties and methods? How do they interact when someone borrows a book?

Exercise 2: The Restaurant Model a restaurant from the moment a guest walks in to when they pay the bill. Objects: Guest, Host, Server, Chef, Table, Menu, Order, Dish, Bill. Draw the sequence diagram for a dinner service.

Exercise 3: Your Morning Routine This one's personal. Model your actual morning as interacting objects. You are an object (properties: energyLevel, hunger, cleanliness; methods: wake(), shower(), eat(), commute()). Your alarm clock is an object. Your shower is an object. Your car or train is an object. How do they interact?

If you completed the pseudocode exercises from Lesson 1, try combining both skills: write the pseudocode for your library system, then draw the object diagram. Notice how the pseudocode describes the sequence and the diagram describes the structure. Both are needed. Neither alone is complete.