Compass : East Oriented

[srm]

Si c'est du East, setBroken est acceptable ?!

Bah oui pourquoi ça ne le serait pas ?!

Dans un contexte précis, la TV doit forcément faire un truc, okay. Je sais ce que je veux, et je te fais confiance pour le faire: c'est applicable aux codes de test? Si oui, alors on a un problème... Si non, okay, ça va, mais cela fait deux paradigmes en fonction du contexte (test vs fonctionnement).

Les tests ça a toujours été le paradigme : je sais ce que tu dois faire et je vérifie que tu le fais
Que tu sois en POO, en fonctionnel etc.

Cette distinction Barman/Policier, pourquoi doit-elle être faite explicitement par un ask*ByBarman et ask*ByPolicier plutôt qu'implicitement par ask* + instanceof? J'aurai plutôt considéré que c'est à la classe appelée de faire, en interne, la distinction entre Policier et Barman, c'est à dire n'avoir qu'une seule méthode ask* et au besoin, un instanceof interne.
D'ailleurs, si le Barman est Policier, comment cela se passe en East? En West, l'appelé prendra sa décision en sachant que c'est un instanceof Policier && instanceof Barman, mais en East? Il faut un ask*ByBothBarmanAndPolicier?

Parce que déjà ça ne sera pas open/close
Et ça t'impose de connaître tous les types d'instances que tu vas avoir, tu es moins abstrait.
Et ça impose à ta boite noire de trop connaître le monde extérieur, savoir tous les types de classes que tu peux avoir.
Pire, prendre des décisions en fonction des type d'instance que tu vas.
Donc prendre des décisions selon un contrat, et les interfaces c'est exactement fait pour ça.
ask*ByBarman, je sais immédiatement dans quel contrat je suis, je n'ai pas à me poser 50 questions et mettre des if dans tous les sens.

SI le Barman est Policier, c'est à lui de choisir comment il se présente.
Puisque c'est lui qui va faire $user->ageAskByBarman($this) ou $user->ageAskByPolicier($this)
Et ton exemple montre bien le soucis du instanceof.
Comment tu gères ça avec un instanceof ? Bah c'est toi la boite noire ($user) qui va prendre la décision.
Alors que c'est le Barman/Policier qui doit choisir comment se présenter, en tant que Barman ou Policier.

J'ai quand même du mal à assimiler un Je sais ce que je veux, et je te fais confiance pour le faire couplé à Je teste que tu as bien fait ce que je veux. J'essaierai de formuler des exemples précis de situations.

En West, je n'ai touché ni à l'interface de Barman, ni à l'interface de Consumer. Je n'ai fait que modifier le code interne de la méthode giveAlgoholToConsumer. Aucune classe tierce ne sera touchée. Elles ne pourront l'être que si l'interface consumer est éditée pour ajouter getReligion (mais on peut faire sans modifier cette interface, en pur Open/Close)

En East, si j'ai compris, il aurait fallut modifier l'interface consumer pour ajouter askReligionByBarman et modifier l'interface du barman pour ajouter religionGivenByConsumer: beaucoup de classes tierces risquent d'être impactées.

J'espère bien que tu vas toucher l'interface Consumer en West !
Si tu ne le fais pas ça veut dire que tu vas appeler Consumer->getReligion alors que c'est défini nul part dans l'interface et tu ne sera donc même pas sur que la méthode existe ! Donc en gros ton interface ne sert plus à rien si tu t'autorise à appeler des choses qui ne sont pas définis dans l'interface.

Beaucoup plus de classes tierces impactées et encore heureux.
Je change le contrat, elles doivent s'y plier, c'est le principe même des interface, faire différement c'est comme si tu utilisais pas les interface.