How would I best and safely wire a parent/children objects together - php

Question

This is my demonstration case:
<?php
declare(strict_types=1);
final class Order
{
/** #var array|OrderPosition[] */
private $orderPositions;
public static function fromArray($orderData)
{
assert(isset($orderData['orderId']));
assert(isset($orderData['positions']));
return
new self(
$orderData['orderId'],
array_map(
function (array $positionData): OrderPosition {
// I would like to put the "future self (Order)" alread here
return OrderPosition::fromArray($positionData);
},
$orderData['positions']
)
);
}
private function __construct(string $orderId, array $orderPositions)
{
$this->orderPositions = $orderPositions;
// what I want to avoid is:
array_walk($orderPositions, function (OrderPosition $position) {
$position->defineOwningOrder($this);
});
}
}
final class OrderPosition
{
/** #var Order */
private $owningOrder;
public static function fromArray($positionData /* + as mentioned I'd like to put the "calling" Order here already...? */)
{
return
new self(
$positionData['productId'],
$positionData['amount']
);
}
private function __construct(string $productId, int $amount)
{
// …
}
/** #internal */
public function defineOwningOrder(Order $order)
{
$this->owningOrder = $order;
}
}
I like to have a pointer to the "parent"/owning Order item in my OrderPosition; however since Order is considered an Aggregate Root I want Order to be in charge of creating the collection of OrderPositions.
How should I put the Order item in every OrderPosition when the final Order is not yet there on creation?
My current approach is to late-set it in Order's ctor but that would mutate OrderPosition, strictly spoken.

Answer 1

You have a combination of several design decisions here which are in conflict:
immutable objects
a circular reference
a constructor which is not responsible for constructing the dependent objects
a factory method which is not allowed to see and mutate a partial object
As you say, your current implementation compromises on (1) by allowing the OrderPosition to have the extra reference added in later.
You can make the problem go away if you remove (2). What is the situation where you would have a reference to an OrderPosition and want to navigate to the Order to which it belongs? Can that situation be re-framed as a responsibility of the Order, removing the circular reference?
You could change (3) such that the constructor took the information to create OrderPositions, not the OrderPositions themselves. In your example, this would be trivial, but if in practise you have a number of different factories feeding into one constructor, this might become messy.
Alternatively, if you relax (4) you could pass the partially constructed object into the OrderPosition constructor / factory:
public static function fromArray($orderData)
{
assert(isset($orderData['orderId']));
assert(isset($orderData['positions']));
$instance = new self($orderData['orderId']);
foreach ( $orderData['positions'] as $positionData ) {
$instance->orderPositions[] = OrderPosition::fromArray($positionData, $instance);
}
return $instance;
}
While this still looks like mutation, it is only the same mutation you would do in any constructor - you are creating the initial state of the object.
In a language that supported overloaded or named constructors, fromArray would be a constructor, and might not share any implementation with other constructors. In PHP, you can emulate that pattern with an empty private function __construct(){} and static methods starting with $instance = new self;