+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Compass : East Oriented (/showthread.php?tid=7165)
RE: Compass : East Oriented - Xenos - 23-06-2015
(peut-être que je passerai pour hermétique, mais bon :p Sympa d'être venu faire un tour en revanche
)Au delà d'instanceof (qui n'a pas de lien de fond avec East), ce qui me tique, c'est qu'on parle de "dépendre des informations [...] communiquées suivant le protocole défini entre eux". Et pour moi, ça, c'est incompatible avec "l'intérêt de east, c'est de maximiser le niveau d'abstraction"
Il me semble que si on veut abstraire les choses, giveGenderToMoneyProvider peut monter d'un cran dans l'échelle d'abstraction, pour devenir giveGenderToSomething, et ça, c'est pareil que getGender. Bien évidemment, pas au sens de m*rde qu'on voit dans les cours qui se veulent d'OO et qui présentent les getters/setters comme des accesseurs d'attributs (ça, ce n'est même plus violer l'encapsulation, c'est la lapider au fond d'une cave humide en chantant du maitre gims), mais bien au sens de je demande une donnée (Gender) à cette entité.
Bref, je ne vois toujours pas en quoi East améliore l'abstraction, en faisant la guerre au mot clef return.
Et au fait, les throw Exception, pour East, ça se passerait comment?
RE: Compass : East Oriented - Ter Rowan - 24-06-2015
(23-06-2015, 07:45 PM)srm a écrit : Ah ah tu plaisantes ?
Car c'est justement ce que je dis depuis le début East c'est pas une réinvention.
C'est juste revenir au fondamentaux
non non je ne plaisante pas, mais les x pages de discussion m'avait amené à croire à un "encore un truc révolutionnaire sans intérêt". C'est quand même bien plus clair avec l'exemple de ton camarade.
Maintenant je suis plutôt comme Xenos pour l'exemple du giveGender / getGender. Ca ressemble fortement en dehors du est / ouest.
Je pense que le East prend tout son sens dans l'appel de méthodes plus complexes que de savoir la couleur ou le sexe d'un sujet oriental (ou d'un objet occidental)
RE: Compass : East Oriented - niahoo - 24-06-2015
Il n'a rien apporté de plus que ce qu'on a dit pendant 3 longues pages …
Et je suis d'accord avec ça :
Citation :Il me semble que si on veut abstraire les choses, giveGenderToMoneyProvider peut monter d'un cran dans l'échelle d'abstraction, pour devenir giveGenderToSomething, et ça, c'est pareil que getGender.
On ne gagne pas en abstraction (edit: avec east), on y perd, parce que un getter c'est un contrat rempli par n'importe quel type.
RE: Compass : East Oriented - srm - 24-06-2015
On veut surtout pouvoir utiliser un objet sans connaitre son fonctionnement interne et pouvoir modifier le fonctionnement interne d'un objet sans se préoccuper du monde extérieur. C'est là ou on voit l'abstraction.
Si je fais giveGenderToSomething($something) ou $something n'est d'aucun type, du coup je ne peux rien faire avec $something, comment je peux lui donner ma donnée si je ne sais pas quel contrat il respecte ?
RE: Compass : East Oriented - niahoo - 24-06-2015
Si tu redéfinis « abstraction » on n'a pas fini … Là tu me parles du simple principe d'encapsulation et d'API.
Si tu me donnes un exemple en east, c'est sûr, ça montre qu'en faisant du east il vaut mieux faire du east. C'est pas faux.
Mais si ton objet implémente implémente une interface
Citizen, il n'a plus besoin d'implémenter giveGenderToMoneyProvider, giveAgeToAccessProvider, giveAgeToAlcoholProvider pour pouvoir avoir de la thune, entrer dans un bar et l'y dépenser. Du coup plus besoin d'étendre cette classe pour implémenter au passage la communication avec les interfaces MoneyProvider, AccessProvider et AlcoholProvider. C'est plus simple et plus abstrait à la fois. Moins d'interfaces, moins de classes et *respire* moins de méthodes. C'est moins moche aussi du coup !Donc là on va repartir sur le type hinting et effectivement, on ne peut pas (encore) type-hinter de simples types de getters. Ceci n'empêche pas d'utiliser les ValueObjects tant loués, et n'augmente pas le niveau d'abstraction.
RE: Compass : East Oriented - srm - 24-06-2015
Si mon objet implémente Citizen il doit toujours implémenter money\provider ou money\consumer selon le rôle qu'il tient.
RE: Compass : East Oriented - niahoo - 24-06-2015
Et bien ton money provider peut s'appuyer sur l'interface Citizen justement, comme les autres services qui utilisent les mêmes infos pour donner des allocs ou pour servir de l'alcohol. L'idée est que le citizen peut donner des informations sans avoir besoin de savoir à qui il s'adresse obligatoirement. C'est le code englobant, celui qui manipule les deux instances, qui s'en occupe.
RE: Compass : East Oriented - srm - 25-06-2015
Je ne comprends pas ce que tu expliques, tu peux donner le code correspondant ?
RE: Compass : East Oriented - niahoo - 25-06-2015
Heu non la méga-flemme, je pense que tu es assez grand pour imaginer un code qui instancie deux classes et qui passe l'instance de l'une dans la méthode de l'autre.
RE: Compass : East Oriented - Xenos - 01-07-2015
Je ne cautionne toujours pas East, mais je me suis attardé sur la question de savoir si tout code West peut-il devenir East, l'inverse étant évidemment vrai, puisque tout code East est déjà un code West. Je me suis restreint au seul principe de "always return null ou $this". Si ça t'intéresse...