Ah, okay, effectivement, avec ces deux règles, cela change des choses 
De ce que j'avais lu des liens que tu as présentés (ou alors, c'était suite à une recherche web? je ne sais plus...), la règle était "pas de data, que des messages", donc j'en avais déduis "pas de value object".
Ca répond à l'autre question que j'allais d'ailleurs poser: pourquoi peut-on faire un [] (getter) sur un array ? Si les array[] sont considérés comme des value objects, c'est réglé. Après, en C++, l'opérateur [] se surcharge (c'est un opérateur comme un autre), donc faire de l'array un value object est plus délicat comme point de vue...
Bon, après, je ne suis quand même pas encore top-convaincu, surtout que j'aurai tendance à sortir les code des case dans des classes séparées (pour avoir, par exemple, un FileAggregator->switchCases[], liste chaînée des classes issues du case). Cela impliquerait de leur passer File $file, $type, $lineNumber, FileUploader $fileUploader, FileAggregator $this en paramètre... Cela commence à en faire, des paramètres (surtout si ces classes ne sont utilisables que par le FileAggregator: j'ai d'autres endroits dans le projet où on peut uploader fichier par fichier, et cette fois sans nomenclature de nom, et avec d'autres types de restrictions).
J'en reviens à ma dernière question: existe-t-il un projet industriel (maintenable) codé en East?
Quoique si, j'en ai une autre de question:
Tous les appels à des function(parameters...) { ... return X; } sont remplacés par des appels à function(resultTreatment, parameters...) { ... resultTreatment->(parameters..., X); } où la classe resultTreatment récupère la suite des opérations à effectuer (en lisant le code, tous les changements West → East se résument à ce genre de remplacements), c'est bien cela?
Est-ce vraiment plus souple? Car outre l'apparition d'une nouvelle classe (ou interface, implémentée par l'appelant), on bascule en fait le typage du retour de function(parameters...) vers un typage de resultTreatment->(parameters..., X) ?!
Dans l'exemple, FileAggregator est dépendant de FileUploader->fileRejected() ? L'ajout de dépendances n'empiète pas sur l'évolutivité du code?
Maintenant, okay, je crois que je visualise mieux comment cela marche, mais le pourquoi m'échappe encore...
De ce que j'avais lu des liens que tu as présentés (ou alors, c'était suite à une recherche web? je ne sais plus...), la règle était "pas de data, que des messages", donc j'en avais déduis "pas de value object".
Ca répond à l'autre question que j'allais d'ailleurs poser: pourquoi peut-on faire un [] (getter) sur un array ? Si les array[] sont considérés comme des value objects, c'est réglé. Après, en C++, l'opérateur [] se surcharge (c'est un opérateur comme un autre), donc faire de l'array un value object est plus délicat comme point de vue...
Bon, après, je ne suis quand même pas encore top-convaincu, surtout que j'aurai tendance à sortir les code des case dans des classes séparées (pour avoir, par exemple, un FileAggregator->switchCases[], liste chaînée des classes issues du case). Cela impliquerait de leur passer File $file, $type, $lineNumber, FileUploader $fileUploader, FileAggregator $this en paramètre... Cela commence à en faire, des paramètres (surtout si ces classes ne sont utilisables que par le FileAggregator: j'ai d'autres endroits dans le projet où on peut uploader fichier par fichier, et cette fois sans nomenclature de nom, et avec d'autres types de restrictions).
J'en reviens à ma dernière question: existe-t-il un projet industriel (maintenable) codé en East?
Quoique si, j'en ai une autre de question:
Tous les appels à des function(parameters...) { ... return X; } sont remplacés par des appels à function(resultTreatment, parameters...) { ... resultTreatment->(parameters..., X); } où la classe resultTreatment récupère la suite des opérations à effectuer (en lisant le code, tous les changements West → East se résument à ce genre de remplacements), c'est bien cela?
Est-ce vraiment plus souple? Car outre l'apparition d'une nouvelle classe (ou interface, implémentée par l'appelant), on bascule en fait le typage du retour de function(parameters...) vers un typage de resultTreatment->(parameters..., X) ?!
Dans l'exemple, FileAggregator est dépendant de FileUploader->fileRejected() ? L'ajout de dépendances n'empiète pas sur l'évolutivité du code?
Maintenant, okay, je crois que je visualise mieux comment cela marche, mais le pourquoi m'échappe encore...