09-04-2015, 11:21 AM
public function destinationFor(Origin $currentOrigin)
{
foreach ($this->routes as $route) {
$route->match($currentOrigin, $this);
if ($this->signalStop === true) {
break;
}
}
return $this;
}
Pour moi, c'est un peu de la contorsion qui ne fait que cacher la conception, plutôt qu'un changement de conception. Je le lis comme une implémentation un peu tordue de
foreach ($this->routes as $route)
if ($route->match($currentOrigin, $this))
break;
Car la respo du Router est de passer le Origin aux éléments, dans l'ordre, et de s'arrêter au premier qui lui renvoie un stop (rien n'oblige le return de match() à valoir true si le match a lieu et false sinon: le return de match peut valoir false ou true, peut importe la raison).
public function newRoute(Route $route)
{
$router = clone $this;
$router->routes[] = $route;
return $router;
}
De même, je ne comprends pas les clone $this. Le contenu de la méthode est une mécanique interne de l'objet, alors pourquoi cloner (même si, justement, on en a le droit puisque c'est interne)? Les "setter" (peut importe le nom qu'on leur donne) ne me semblent pas casser l'OO "originel" (si on considère qu'ils ne font qu'envoyer un message à l'objet, et non casser l'encapsulation en settant une de ses propriétés); ni même les getter d'ailleurs (si là aussi, on considère qu'on ne get pas une propriété de l'objet, mais une information que l'objet sait nous donner/créer/récupérer).
Dire juste "setter / getter ne servent pas à définir des propriétés de l'objet" (mieux vaut passer la propriété publique du coup, façon Bean) me semble plus pertinent finalement.
'fin bref, finalement, j'adhère pas trop; peut-être parce que PHP n'est pas du tout adapté à l'OO au fond, car l'OO me semble être obligatoirement exécutée sur une architecture parallèle où les thread/entités s'envoient des messages, plutôt qu'une archi série (et PHP ne fait pas de parallélisme entre ses objets).