Arrays can hold values.
Associative arrays can label values.
But sometimes the data you're working with is more than that
— it's a thing, a concept in your system, something that deserves a name.

That's when objects enter the picture.

Objects give shape, meaning, and guarantees to your data.
They turn loose values into something intentional.

Consider this associative array:

$user = [
    "name" => "Tony",
    "age" => 99,
    "is_active" => true,
];

It works.
But it also hides meaning:

• What is a user?
• Which fields are required?
• What types should they be?
• Can the data be invalid?
• What does a user do?

You're no longer dealing with “just data”.
You're describing a thing — a concept in your system — a domain model.

That's when a class becomes the clearer, safer choice.

A simple class:

class User {
    public string $name;
    public int $age;
    public bool $is_active;
}

Now the idea has a name (User).
The structure is visible (public).
The types are guaranteed (string, int, bool).
The meaning is explicit.

Objects turn implicit assumptions
into explicit design.

Objects give you:

• structure — the shape is fixed
• meaning — the name tells the story
• validation — you can enforce rules
• autocomplete — your editor understands the shape
• safety — typos become errors, not silent bugs
• behavior — methods express what the concept does

Objects are not about complexity.
They’re about clarity.

Arrays can hold data,
but they can't express behavior.

Objects can:

class User {
    public string $name;
    public int $age;
 
    public function isAdult(): bool {
        return $this->age >= 18;
    }
}

Now the concept carries its own logic. The rule lives where it belongs.

This is the beginning
of modeling.

Use an object when the data:

• represents a real concept
• has rules
• has behavior
• deserves a name
• appears in multiple places
• needs clarity and guarantees

Objects are not required for everything.
But when meaning appears, objects make it visible.

Not everything deserves a class, of course.

Avoid objects when the data is:

• small
• temporary
• configuration‑like
• simple
• not meaningful

This is why arrays still matter.
Objects are for concepts.
Arrays are for values.

Objects are not about “object‑oriented programming”.
They're about naming the important things in your system.

Use them when:

• the data has identity
• the structure matters
• the meaning is real
• the rules belong together

Objects turn scattered values
into a coherent idea.

_{Tony de Araujo —New York}

• Top↑
• Back to Topic ↔
• Home←