Compass : East Oriented

[srm]

Le soucis et l'avantage de la souplesse et des modifications open/close, puisqu'au moins je peux lui répondre ce que je veux au Barman alors qu'avec un getter je ne peux pas.

Je n'ai pas compris la phrase :\ Je re-soulève le point que PHP n'a pas de typage de retour (les type hintings sont tous facultatifs).

C'est bien ce que je dis, c'est un soucis certes dans une certaine mesure, mais cette méthode à d'avantage de souplesse et vu que j'ai askAgeByBarman($barman) je peux très bien faire : $barman->userAgeIs($this->age + 30);
Donc mentir à un Barman mais si j'ai askAgeByStats là je vais répondre $this->age.
Avec getAge() je ne peux pas faire ce genre de choses. Je ne suis pas souple.

Peut-être pas 50 classes, okay, mais plusieurs, ce qui veut dire que les changements devront être fait à d'autres endroits du code que là où le changement est demandé. Faudrait, pour éviter cela, que East permette d'avoir une approche d'ajout d'interfaces plutôt que d'édition d'interfaces.

Dans ton exemple tu montres toi même deux problème avec ta méthode.
// Note qu'on présume que askAge renvoie un age en année,
// Il serait plus pertinent de ne pas présumer puisque ce n'est pas dans le contrat d'interface

Ca c'est un soucis majeur.
Tu as des interfaces mais tu ne peux pas te reposer dessus pour avoir un code fiable alors que c'est leur but et principe.

Et que tu nommes askAge ou getAge tu est obligé de faire le même type d'action quelque soit l'objet qui le demande.
Tu n'as pas de soupless et d'extensibilité possible selon ne type d'objet qui te demande l'information.

Tu dois modifier toutes les classes qui implémente l'interface oui.
C'est là que le semver devient important.
Et qui fait que justement ça coincera pas. Mais respecter le semver n'a pas de rapport avec East en soit.
C'est juste utiliser des bonnes pratiques, le problème que tu soulèves se pose aussi quand tu ne fais pas du East.

Et c'est parfaitement logique, de toujours respecter les interfaces et n'utiliser que ce qu'elles définissent permet d'éviter pas mal d'erreurs masquées.

La méthode de composition que tu proposes, tu peux la faire aussi en East, mais tu as moins de souplesse si tu fais comme ça.
Si tu veux avoir comportement askAge différent si la personne qui te le demande est religieuse ou non, tu es bloquée.
Ou alors tu vas devoir ajouter des instanceof. Donc ne pas respecter l'open/close principe et en plus tu vas devoir connaître l'objet extérieur avec lequel tu travails, donc une dépendance plus forte.