Classes and Objects

A checkout service keeps each customer as an array:

$customer = ['id' => 17, 'email' => 'ada@example.com', 'credits' => 10];
$customer['emial'] = 'typo@example.com';   // no error, no warning
applyDiscount($customer, 1.5);

The array carries an implicit contract — which keys exist, which types they hold, which values are legal — and PHP enforces none of it. The typo'd key silently becomes a second field, applyDiscount may read credits as a string and concatenate it into nonsense, and every function that touches the array re-implements (or forgets) the same checks. A class makes the contract a single declaration:

final class Customer
{
    public function __construct(
        public int $id,
        public string $email,
        public int $credits,
    ) {
        if ($credits < 0) {
            throw new InvalidArgumentException('credits cannot be negative');
        }
    }
}

This uses constructor property promotion, added in PHP 8.0: writing public int $id in the constructor signature declares a typed property and assigns it — no separate property block, no manual $this->id = $id lines. The pre-8.0 form is worth reading once so the promotion is not magic:

class Customer
{
    public int $id;
    public string $email;
    public int $credits;

    public function __construct(int $id, string $email, int $credits)
    {
        $this->id = $id;
        $this->email = $email;
        $this->credits = $credits;
    }
}

Both forms deliver the property interviewers probe: typed properties reject wrong assignments before any method runs. new Customer('17', 'a@b.c', 5) throws a TypeError at the construction site — not three functions later when someone computes $customer->id + 1. And because validation lives in the constructor, every instance of Customer has passed the same gate; there is no partially built object for callers to defend against. With arrays, that invariant was every caller's private homework.

Two mechanics complete the blueprint. $this inside a method is the instance the method was called on: $customer->spend(4) binds $this to $customer, so the method sees that object's state. And a typed property with no default starts uninitialized — reading it throws Error: Typed property Customer::$credits must not be accessed before initialization rather than quietly yielding null. That is deliberate: null is the phantom state arrays let you smuggle past every check.

Finally, each new produces an independent instance with its own copy of the property values. Two customers built from the same database row share nothing:

$a = new Customer(17, 'ada@example.com', 10);
$b = new Customer(17, 'ada@example.com', 10);
var_dump($a === $b);          // bool(false) — two distinct instances
get_debug_type($a);           // 'Customer'

Behavior belongs next to the state it protects: a spend(int $amount): void method keeps the credits invariant inside the class, where the array version left it to memory. Whether outsiders may touch $customer->credits directly is the next decision — Public, Private, and Protected Members makes it.

One more contrast with arrays repays attention: initialization order. An array is valid at every moment of its construction — half-filled keys and all — while a class instance springs into existence already consistent, because the constructor is a single indivisible step. Frameworks exploit this: an object hydrated by an ORM passes through the same constructor gate your manual new does, so database-originated instances obey identical invariants. The habit to leave this chapter with is to treat the constructor signature as the class's public API — every parameter is a promise about what a valid Customer is, and every promoted typed property is that promise checked at the call site.

This topic picks up where Regular Expressions left off: that phase's examples carried data in loosely shaped strings and arrays, and the class blueprint above is exactly what turns those loose shapes into contracts the engine enforces.

Assigning an object does not copy it — objects are handles:

$a = new Customer(17, 'ada@example.com', 10);
$b = $a;                       // two names for ONE instance
$b->credits = 0;
var_dump($a->credits);         // int(0) — changed through $b

This is the sharpest behavioral difference from arrays, which have value semantics: $copy = $arr followed by mutating $copy leaves $arr alone. With objects, both variables point at the same instance, so a mutation through either is visible in both. Passing an object into a function has the same effect — the function receives the handle, so a method that mutates a property changes what the caller sees. That is the mechanism behind dependency injection and every ORM in PHP, and it is also how aliasing bugs sneak in when two modules share an object neither expected the other to touch.

When you do want an independent copy, clone makes a new instance:

$c = clone $b;                 // new Customer; scalar properties copied
$c->credits = 99;              // does not affect $b

But clone is shallow: nested objects among the properties are copied as handles, so a deep copy needs the __clone hook to re-clone the internals (public function __clone(): void { $this->address = clone $this->address; }). A second route to a fresh instance is the constructor itself — new Customer($a->id, $a->email, $a->credits) — which often states intent better than cloning a mutable object anyway.

Two operators answer different questions about objects, and conflating them is a review-blocking bug:

$a == $b    // same class AND equal property values (compared loosely, property by property)
$a === $b   // the SAME instance — identity, properties never inspected
$a !== $b   // different instances

== walks the property tables using loose comparison semantics, so an object whose id is '17' still counts equal to one whose id is 17. === never looks at a single property: it asks whether both names point at one object. The practical rule: use ===/!== for objects by default. Reserve == for deliberate value objects — money, coordinates, immutable DTOs — where structural equality is the meaningful question, and then implement it predictably.

Because identity is what matters, a few identity utilities come with the language. $a instanceof Customer is the type check. spl_object_id($a) (PHP 8.0) returns a small unique int per live object. And since arrays cannot use objects as keys, "a set of customers" or "count per customer" needs spl_object_storage or the 8.0 WeakMap, which removes entries automatically when an object is garbage-collected. Knowing that objects are handles also explains a deprecation you will meet on modern code: assigning a value to a property the class never declared. PHP 8.2 deprecated dynamic properties — the fixes, and the string/JSON faces of an object, are in Methods, Factories, and the Shape Callers See.

Identity also explains the container utilities you will reach for in real code. spl_object_storage pairs each object with attached data and answers contains() by identity; the 8.0 WeakMap does the same while removing entries automatically the moment a key is garbage-collected, which makes it the correct home for per-object caches — the array version leaks every entry until someone remembers to prune it. And when a function must test what a value is, $x instanceof Customer beats get_class($x) === 'Customer', because instanceof also answers true for subclasses — exactly the behavior polymorphism depends on, and exactly what breaks when == stands in for identity in a conditional.

A class is not only state plus methods; it is also the place where you decide how instances come into existence and how they appear to the outside world.

Static factories build an instance from data that is not yet a valid constructor call — an array row, a JSON payload, a database record:

public static function fromRow(array $row): self
{
    return new self((int) $row['id'], (string) $row['email'], (int) $row['credits']);
}

$customer = Customer::fromRow($pdoRow);

The name fromRow tells the caller what shape the argument must be, something new Customer(...) at a call site with six arguments never communicates. Factories are static because they produce an object; they must not touch $this, since no instance exists yet — you will see the full static-versus-instance rules in Static Properties and Methods.

Fluent methods return $this so calls chain, and since PHP 8.0 the static return type keeps chaining correct in subclasses:

public function withCredits(int $credits): static
{
    $this->credits = $credits;
    return $this;
}

$customer = (new Customer(17, 'ada@example.com', 10))->withCredits(25);

Returning static rather than self matters when a subclass overrides the method: the chained value stays the subclass type instead of being widened back to the parent.

Output and serialization are decisions, not accidents. An object is neither a string nor JSON by default:

echo $customer;                  // Error: Object of class Customer could not be converted to string
json_encode($customer);          // dumps public properties — usually not the API contract you want

Implement JsonSerializable to put the wire format inside the class, where a property rename cannot silently change what an API ships:

final class Customer implements JsonSerializable
{
    public function jsonSerialize(): array
    {
        return ['id' => $this->id, 'email' => $this->email];
    }
}

For string contexts, the magic method __toString() plays the same role — echo $customer becomes the returned string. It must not throw, and you will cover it properly in Magic Methods like __get and __toString.

Finally, the modern-PHP landmine: $customer->nickname = 'ada'; on a class that never declared $nickname creates a dynamic property, deprecated since PHP 8.2 — it emits Deprecated: Creation of dynamic property Customer::$nickname and will eventually be an error. The fix is declaring the property with a type; the explicit opt-out #[AllowDynamicProperties] exists for genuinely open containers (and stdClass already has it). Declaring the property is almost always the right answer: the property you were about to invent was part of the class's contract all along.

Two inspection helpers close the loop on everyday object work. get_debug_type($customer) returns the precise class name — or 'null', 'int', 'string' for scalars — which beats var_dump inside log lines and error reports, and $customer::class yields the class name as a string wherever a name is needed rather than an instance. Reflection is the heavyweight option: (new ReflectionClass($customer))->getProperties() enumerates the declared shape at runtime, which is how var_dump, JSON serializers, and ORM mappers work under the hood. The through-line of all three chapters is that a class is a contract made checkable: types the engine enforces, identity rules the comparison operators implement, and representations the class itself decides. Reach for arrays when you want a bag of scalars with value-copy semantics; reach for a class the moment the data has invariants, behavior, or a name worth defending in review.