Object value pattern - obsolete with php 5?

[johanafm]

I found a book from 2005 on php design patterns at the office and had a look at it. The book presents solution both for php 4 and 5.

The first presented pattern was called Object value pattern, and the presented code has been bugging me since I read it. Did I missunderstand something, or was this an issue due to lack of access modifiers in php 4?

I wrote some code which ought to show the concept, the book's presented solution and the way I'd go. If something seems strange in all this, I could of course present code identical to that found in the book but with other class, function and variable names to get around copy right issues. Just let me know in that case.

Original code. The problem is that those two people share the same wallet. The public access is a problem in my books, while them sharing one wallet isn't necessarily a problem.

class Wallet {
	private $cash;

public function __construct($cash = 0) {
	$this->cash = $cash;
}

public function add($cash) {
	$this->cash += $cash;
}

public function getCash() {
	return $this->cash;
}
}

class Person {
	public $wallet;

public function payDay($amount) {
	$this->wallet->add($amount);
}

public function getCash() {
	return $this->wallet->getCash();
}
}

$w = new Wallet();
$p1 = new Person();
$p1->wallet = $w;
$p2 = new Person();
$p2->wallet = $w;

$p1->payDay(200);
echo $p1->getCash()."\n";
$p2->payDay(200);
echo $p2->getCash()."\n";
echo $p1->getCash()."\n";

Book's presented solution

class Wallet {
	private $cash;

public function __construct($cash = 0) {
	$this->cash = $cash;
}

// Seriously? This seems messed up to me...
public function add($cash) {
	$w = new Wallet($cash + $this->cash);
	return $w;
}

public function getCash() {
	return $this->cash;
}
}

class Person {
	public $wallet;

public function payDay($amount) {
	$this->wallet = $this->wallet->add($amount);
}

public function getCash() {
	return $this->wallet->getCash();
}
}

$w = new Wallet();
$p1 = new Person();
$p1->wallet = $w;
$p2 = new Person();
$p2->wallet = $w;

$p1->payDay(200);
echo $p1->getCash()."\n";
$p2->payDay(200);
echo $p2->getCash()."\n";
echo $p1->getCash()."\n";

My preferred approach

// My approach
class Wallet {
	private $cash;

public function __construct($cash = 0) {
	$this->cash = $cash;
}

public function add($cash) {
	$this->cash += $cash;
}

public function getCash() {
	return $this->cash;
}
}

class Person {
	private $wallet;

public function __construct() {
	$this->wallet = new Wallet();
}

public function payDay($amount) {
	$this->wallet->add($amount);
}

public function getCash() {
	return $this->wallet->getCash();
}
}

$w = new Wallet();
$p1 = new Person();
$p2 = new Person();

$p1->payDay(200);
echo $p1->getCash()."\n";
$p2->payDay(200);
echo $p2->getCash()."\n";
echo $p1->getCash()."\n";

Additionally, you might want to actually let people share the same wallet, bank account or whatever. And what would be the best way to deal with wallet sharing? Something like this?

class Person {
// ... as before

public function shareWalletWith($person) {
	$person->acceptWallet($this->wallet);
}

public function acceptWallet($wallet) {
	$this->wallet = $wallet;
}
}

[laserlight]

Doing a search on the Web is not very promising for 'php "object value pattern"'. On the other hand, 'php "value object pattern"' is much more promising.

Looking at the various articles at a glance, I am of the opinion that this pattern makes more sense in PHP 5 than in PHP 4. In PHP 4, object variables are variables that contain value objects. In PHP 5, object variables are variables that contain references to objects, where these references are like pointers without pointer syntax and pointer arithmetic.

So, in PHP 4, your first code example should not result in any sharing of Wallet objects. Rather, $p1 and $p2 have separate copies of $w. In fact, this is why you might see assignment by reference in PHP 4 code, whereas in PHP 5 that is unnecessary if you are merely interested in an optimisation.

The example seems particularly contrived because of the public member variable. We could change it to private and have a constructor for Person that just assigns the reference passed to the member variable, and the same problem of sharing would occur even though the public access problem has been fixed.

Of course, the implementer of the Person class could avoid this sharing problem by making a copy of the object that the reference passed refers to, but I think that the idea behind this design pattern is to make the Wallet class itself able to avoid the effects of being shared. Basically, you just make it immutable, and have otherwise mutable methods return a reference to a new object of the given class that contains the result of the operation.

[johanafm]

Simple examples often are contrived. Your immutable explanation makes sense though. Thanks.