The Value Object Pattern 41

$this->assertEqual(400, $p1->wallet->getAmount());

//this is bad - actually 400 $this->assertEqual(200, $p2->wallet->getAmount());

//this is really bad - actually 400 $this->assertEqual(200, $job->payDay()->getAmount()); }

So, what’s the bug? If the test case didn’t make the problem apparent, here’s a hint: employees $p1 and $p2 share the same BadDollar.

First, instances of Work and Person are created. Then, assuming that each person initially has an empty wallet, Person::wallet is set to the BadDollar object returned by Work::payDay().

Remember your “friend” the PHP 5 object handle? Because of it, $job::salary, $p1::wallet, and $p2::wallet, three conceptually different objects with different “identities,” actually all refer to the same object.

So, the second pay day, $job->payDay(), which was intended just to fatten the wallet of $p1, inadvertently pays $p2 again and changes the base $salary of $job. Hence, the last two assertions fail:

Value Object PHP5 Unit Test

1) Equal expectation fails because [Integer: 200] differs from [Float: 400] by 200

in testBadDollarWorking in ValueObjTestCase

2) Equal expectation fails because [Integer: 200] differs from [Float: 400] by 200

in testBadDollarWorking in ValueObjTestCase FAILURES!!!

The Problem

So, how do you implement a lightweight, or easy to construct, descriptive object like Date or Dollar?

The Solution

Lightweight objects should behave like PHP integers: if you assign the same object to two different variables and then change one of the variables, the other variable should remain unaffected. And indeed, this is the goal of the Value Object pattern.

Implementing Value Object differs between PHP 4 and PHP 5.