Make objects initially inconsistent, yet eventually immutable
Latest commit f40205a Jan 12, 2016 @matthiasnoback Add a warning
[skip ci]
Failed to load latest commit information.
src Initial commit Jan 12, 2016
test Initial commit Jan 12, 2016
.gitattributes Initial commit Jan 12, 2016
.gitignore Add code coverage details Jan 12, 2016
.travis.yml Make the build faster Jan 12, 2016
LICENSE Initial commit Jan 12, 2016 Add a warning Jan 12, 2016
composer.json Initial commit Jan 12, 2016
phpunit.xml.dist Add code coverage details Jan 12, 2016

Convenient immutability for (some) PHP objects

Warning: I didn't use this library "in the wild" - please let me know if it works in your situation

Build Status Coverage Status


Just run:

composer require matthiasnoback/convenient-immutability


I've often encountered the following situation (in particular when working with command objects).

  1. I start with a simple object (in fact, a DTO), with just some public properties.
  2. The Symfony Form component copies some values into the object's properties.
  3. I copy some extra data into the object (like a generated UUID).
  4. I then use that object as a command or query message, handing it over to some inner layer of my application.

In other words, I have a class that looks like this:

class OrderSeats
    public $id;
    public $userId;
    public $seatNumbers = [];

And use it like this:

$form = $this->factory->create(new OrderSeatsFormType());
$command = $form->getData();
$command->id = Uuid::uuid4();


Then I want it to be impossible to change any field on the (command) object, making it effectively immutable.

The ConvenientImmutability\Immutable trait solves this problem. When your class uses this trait, it:

  • Allows form components and the likes to put anything in your object in any particular order they like.
  • Allows you to get the data from it by simply accessing its (public) variables.
  • Doesn't allow anyone to overwrite previously set data.

Why would you do this?

  • To feel less insecure about using public properties for your desirably immutable objects.
  • To prevent accidental writes to objects you assumed were immutable.

What's the problem with this approach?

  • Your objects may be immutable...
  • but they can still exist in an inconsistent state.

Is this bad? I don't think so. As long as you validate the objects (e.g. using the Symfony Validator) and then throw them into your domain layer, which contains the actual safeguards against inconsistent state.

(You can also just use public properties and treat them as "set once, never again" in other parts of your application.)