Cas 5 : avant de donner mes papiers je veux savoir le matricule du policier.
C'est sûr que si askPaper() ne reçoit pas l'objet Policier (qui n'est d'ailleurs pas nécessairement l'appeleur de la méthode), askPaper() ne pourra pas discriminer les tâches à faire sur la base du matricule du Policier (puisque askPaper n'a pas accès au Policier).
Ce n'est donc pas une question d'East/West, mais une question de passer les paramètres utiles à la méthode appelée.
Même si tu type le retour, tu es dépendant du type de retour vu que ça n'est pas toi qui choisis le retour.
J'ai toujours pas compris: l'appelé choisit le typage du retour, donc, pas de problème? L'appeleur ne le choisit pas, okay, mais c'est lui qui lance le message (appelle la méthode), donc, cela veut dire que cette méthode (et sont typage de retour suivant les langage) lui conviennent?!
Ou alors, si c'est le typage de retour qui ne convient pas à l'appeleur, c'est juste qu'il lui manque un pattern Adapter à appliquer?!
Donc, là, l'avantage que tu exposes, c'est détecter les erreurs à la compilation plutôt qu'au RunTime? Okay, ça, je suis d'accord sur le principe.
En revanche, cette situation est spécifique à PHP: on aura des erreurs de compile sur Java ou C++ par exemple, mais même dans le cas de PHP, j'ai deux objections:
• La prochaine version implémentera (d'après niahoo) le typage des retours, donc la compilation sera cassée
• Le langage PHP actuel part du principe que les retours sont non typés, donc si un code considère qu'un retour est toujours d'un typage donné, en PHP, c'est une erreur puisque le langage autorise n'importe quel retour. Du coup, les codes "mal faits" (qui "typent" les retours alors que le langage ne le fait pas) seront effectivement cassés. Les bons codes (qui vérifient les retours car ceux-ci sont non-typés) ne seront pas cassés: PotDeVin tombera dans les if (!is_a($retour, Papiers)) throw new \Exception(...);.
C'est pour cela que East me semble rajouter, au niveau du code du développeur, des composantes qui sont en fait du ressort du langage lui-même, et ce genre de mélange de couches, je suis contre (le jour où le langage évolue, tous les "bricolages" de dev qui visaient à compenser un truc du langage seront inutiles et pollueront le code).
D'ailleurs, en West, Delinquant pourra retourner un PotDeVin sans cassure de code:
• Créer une nouvelle interface PapiersFictifs
• Y mettre ce que l'interface Papiers avait
• Etendre l'interface PapiersFictifs dans Papiers (interface Papiers extends PapiersFictifs)
• Optionnel: supprimer le contenu de Papiers qui est remonté dans PapiersFictifs
• Créer l'interface PotDeVin qui étends PapiersFictifs
• Modifier le typage de retour dans l'interface Gens, pour retourner PapiersFictifs
• Retourner un PotDeVin dans Delinquant
Ainsi:
• Delinquant et TypeNormal implémentent toujours l'interface Gens
• Les codes qui utilisaient le Papiers retourné par TypeNormal ne sont pas cassés
C'est sûr que si askPaper() ne reçoit pas l'objet Policier (qui n'est d'ailleurs pas nécessairement l'appeleur de la méthode), askPaper() ne pourra pas discriminer les tâches à faire sur la base du matricule du Policier (puisque askPaper n'a pas accès au Policier).
Ce n'est donc pas une question d'East/West, mais une question de passer les paramètres utiles à la méthode appelée.
Même si tu type le retour, tu es dépendant du type de retour vu que ça n'est pas toi qui choisis le retour.
J'ai toujours pas compris: l'appelé choisit le typage du retour, donc, pas de problème? L'appeleur ne le choisit pas, okay, mais c'est lui qui lance le message (appelle la méthode), donc, cela veut dire que cette méthode (et sont typage de retour suivant les langage) lui conviennent?!
Ou alors, si c'est le typage de retour qui ne convient pas à l'appeleur, c'est juste qu'il lui manque un pattern Adapter à appliquer?!
Donc, là, l'avantage que tu exposes, c'est détecter les erreurs à la compilation plutôt qu'au RunTime? Okay, ça, je suis d'accord sur le principe.
En revanche, cette situation est spécifique à PHP: on aura des erreurs de compile sur Java ou C++ par exemple, mais même dans le cas de PHP, j'ai deux objections:
• La prochaine version implémentera (d'après niahoo) le typage des retours, donc la compilation sera cassée
• Le langage PHP actuel part du principe que les retours sont non typés, donc si un code considère qu'un retour est toujours d'un typage donné, en PHP, c'est une erreur puisque le langage autorise n'importe quel retour. Du coup, les codes "mal faits" (qui "typent" les retours alors que le langage ne le fait pas) seront effectivement cassés. Les bons codes (qui vérifient les retours car ceux-ci sont non-typés) ne seront pas cassés: PotDeVin tombera dans les if (!is_a($retour, Papiers)) throw new \Exception(...);.
C'est pour cela que East me semble rajouter, au niveau du code du développeur, des composantes qui sont en fait du ressort du langage lui-même, et ce genre de mélange de couches, je suis contre (le jour où le langage évolue, tous les "bricolages" de dev qui visaient à compenser un truc du langage seront inutiles et pollueront le code).
D'ailleurs, en West, Delinquant pourra retourner un PotDeVin sans cassure de code:
• Créer une nouvelle interface PapiersFictifs
• Y mettre ce que l'interface Papiers avait
• Etendre l'interface PapiersFictifs dans Papiers (interface Papiers extends PapiersFictifs)
• Optionnel: supprimer le contenu de Papiers qui est remonté dans PapiersFictifs
• Créer l'interface PotDeVin qui étends PapiersFictifs
• Modifier le typage de retour dans l'interface Gens, pour retourner PapiersFictifs
• Retourner un PotDeVin dans Delinquant
Ainsi:
• Delinquant et TypeNormal implémentent toujours l'interface Gens
• Les codes qui utilisaient le Papiers retourné par TypeNormal ne sont pas cassés