'Php, how to implement a perfectly immutable builder class?
as I see, the immutability and builder-pattern are paradox. You cannot achieve the same at the same time.
final class Builder
{
private array $data = [];
public function setName(string $v) : self
{
$this->data['name'] = $v;
return $this;
}
public function setId(int $v) : self
{
$this->data['id'] = $v;
return $this;
}
public function toArray() : array
{
return $this->data;
}
}
$builder = new Builder();
$builder->setName('test')->setId(3);
it's simple to do, but violates the immutability: $this->data changes two times.
Of course there is a little workaround, which smells like "wooden iron ring":
final class Builder
{
readonly private string $name;
readonly private int $id;
public function setName(string $v) : self
{
$this->name = $v;
return $this;
}
public function setId(int $v) : self
{
$this->id = $v;
return $this;
}
public function toArray() : array
{
return ['name' => $name, 'id' => $id];
}
}
$builder = new Builder();
$builder->setName('test')->setId(5);
this theoretically implements the immutability, but still smelly. The definition: "
immutable classes define objects which, once created, never change their value
" but this not preciselly applies here. After Builder created, values changed after constructed.
Of course, the ultimate solution:
final class Builder
{
readonly private string $name;
readonly private int $id;
public function __construct(string $name, int $id)
{
$this->name = $name;
$this->id = $v;
}
public function toArray() : array
{
return ['name' => $name, 'id' => $id];
}
}
but this is why Builder used instead of this. What if there are 10 parameters? What is not all is required?
Anyway, is it neccessary to have immutable class in case like that? The Builder object itself won't be used, only its ->toArray() result!
Solution 1:[1]
This sound all very theoretical, without actually considering why these theoretical concepts were created. Why would we want to use immutable objects?
I can name a few advantages:
- They are more efficient because they just exist, without having to do any computation.
- Since they don't change, they can be shared between different sections of a program, without having to check their content.
- They can't change, which could always be a security risk without the proper checks.
- They are often quite simple and easy to understand, and that's what programming is mostly about.
However, objects don't have to be immutable. More often objects are mutable, and that's fine. Your program would do nothing without mutable objects.
Don't fret over these theoretical concepts. They exists to help you understand what you're doing and what the consequences are, but they are not ironclad laws. You are allowed to break them and ignore them, as long as you know what you're doing.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | KIKO Software |
