JeuWeb - Crée ton jeu par navigateur
Compass : East Oriented - Version imprimable

+- 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)

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30


RE: Compass : East Oriented - Xenos - 05-06-2015

Oui, tu lui passes ce que tu veux (t'as choisi ce contrat de méthode-là, alors, j'ai suivi).

Si askGold ne doit marcher que pour un typage donné, oui, tu typehint cette méthode. Relis Ajout sans changement d'interface ni de classe et tu verras que la méthode est typée, car elle n'est prévue que pour accepter IAlcoholConsummer, mais ce Barman a choisi de discriminer ses consommateurs en fonctions de critères persos, internes à la classe.

Un autre Barman pourrait faire:
Code PHP :
<?php 
class MecanicalBarman implements IBarman {
/**
* Screw humans, I won't give you alcohol.
*/
public giveAlcoholTo(IAlcoholConsummer $consummer) {
return
(
$consummer->askAge() > $this->minAge && !$consummer instanceof IHuman)
? new
Alcohol() : null;
}
}
Si d'autres nous lisent, je veux bien qu'ils reformulent ce que j'essaie de faire passer, cela pourra peut-être aider Smile


Comment tu ferais, toi, avec tes brouettes de méthodes pour que Barman serve les gens en fonction de leur age et leur religion, et pour que MecanicalBarman les servent en fonction de leur age et du fait qu'ils ne soient pas des humains?


RE: Compass : East Oriented - Ter Rowan - 05-06-2015

(05-06-2015, 12:03 PM)Xenos a écrit : Note2 : l'algo de Conan est étrange: si un objet est Beggar&Kid&Femme, il lui file 3x son or... Smile
Non c'est n'importe quoi, il renvoie 11.5 fois l'or demandé
C'était my two gold coins

En fait les questions que je me pose sont plutôt :

Est ce que EAST et WEST ne sont pas équivalents pour des développeurs rigoureux (avec derrière chacun préfère sa version) ? c'est ma vision aujourd'kui après vos discussions

Est ce EAST ou WEST qui force le plus la rigueur au développeur non rigoureux ?

En effet ce que je vois de vos deux approches c'est que les deux sont pour moi chiantes/complexes (trop de truc à coder, etc..) ==> me connaissant, je sais que ce que je trouve chiant (au delà du blabla) est plus un aspect rigueur qui me manque (je sais même pas si je fais du mauvais east ou du mauvais west intuitivement) qu'une critique des concepts

donc je me dis si j'avais une équipe de développeurs de faible niveau, quelle stratégie devrais je leur imposer ?


RE: Compass : East Oriented - Xenos - 05-06-2015

C'est vrai que East & West respectant le langage, les deux approches sont parfaitement utilisables (mais on aura vu vers quoi tend ma préférence ^^ ). Mais je doute encore de la viabilité à long terme d'une approche East (à cause du foisonnement de méthodes).


Si tu veux de la rigueur, choisis d'abord un langage fortement et statiquement typé comme Java ou C++.
PHP ou Python ont des typages souples, ce qui veut dire plus de liberté (et de responsabilité) au développeur.

Pour PHP >= 7, aucune des deux méthodes n'aurait vraiment plus de rigueur que l'autre entre East et West, puisque c'est le typehinting qui fixera les libertés aux appels de méthodes et à leurs retours. Je dirai quand même que West sera plus rigoureux car il permet d'une part de forcer le développeur à retourner quelque chose de valide (si le retour est typehinté par GoldCoin, le développeur est forcé de retourner null ou un GoldCoin; en East, le développeur n'y est forcé que s'il n'oublie pas d'appeler la méthode $coinReceiver->getGoldCoin($gold)) et d'autre part de respecter intégralement l'Open/Close principle.

Pour PHP < 7, East est bien plus fermé et verrouillé que West, puisque les "retours" sont typés: on force ce qui était un return à devenir un paramètre de méthode, qui lui peut être typé en PHP < 7. East serait donc potentiellement plus rigoureux.


Mais, si East verrouille plus le développeur grâce au typehinting des return implicites, il ne permet pas de séparer mentalement le fait que la signature de la méthode indique ce à quoi l'objet peut répondre et que le contenu de la méthode décrit comment il y répond. Je pense que cette idée là est plus importante pour progresser qu'une rigueur forcée.


Tout dépend en fait de ce que tu entends pas "rigueur".
Est-ce le fait d'interdire au développeur de faire d'éventuelles conneries (gardiennage)? Ou le fait pour le développeur de bien comprendre le rôle de chacun des éléments qu'il utilise (apprentissage)?


RE: Compass : East Oriented - niahoo - 05-06-2015

@Ter Rowan Ah non mais le coup des instanceof c'est quand même pour faire du East dans les deux cas. Là c'est juste pour savoir s'il vaut mieux plus de méthodes avec le type hinting qui permet de lever des erreurs automatiquement, ou moins de méthodes pour un code plus clair mais avec des checks manuels et des Barbares surendettés.

J'avoue que comme toi, pour moi dans les deux cas c'est juste chiant aussi comme façon de coder.

(Edit je sais que lé débat est pas vraiment sur ce que je dis ... mais bon les deux façons d'écrire sont indépendantes des deux façons d'architecturer)


RE: Compass : East Oriented - srm - 05-06-2015

J'ai justement pas mis de typehint car tu ne veux pas de askGoldByBeggar(Beggar $beggar)
Et je montre les problèmes que ça soulève, tu dois coder avec une doc et tu ne sais pas tous les types d'objet avec lequel le Hero peu travailler.

Donc pour utiliser Hero tu dois lire le code de la classe ou lire une doc, c'est pas du tout la bonne façon de programmer.
Normalement tu lis juste l'interface et tu es souple et je peux ajouter une classe Women et je sais direct que Hero ne l'a gère pas.


RE: Compass : East Oriented - srm - 05-06-2015

(05-06-2015, 02:43 PM)Ter Rowan a écrit : En fait les questions que je me pose sont plutôt :


Est ce que EAST et WEST ne sont pas équivalents pour des développeurs rigoureux (avec derrière chacun préfère sa version) ? c'est ma vision aujourd'kui après vos discussions

Est ce EAST ou WEST qui force le plus la rigueur au développeur non rigoureux ?

En effet ce que je vois de vos deux approches c'est que les deux sont pour moi chiantes/complexes (trop de truc à coder, etc..) ==> me connaissant, je sais que ce que je trouve chiant (au delà du blabla) est plus un aspect rigueur qui me manque (je sais même pas si je fais du mauvais east ou du mauvais west intuitivement) qu'une critique des concepts

donc je me dis si j'avais une équipe de développeurs de faible niveau, quelle stratégie devrais je leur imposer ?

Tu fais du West, car en West tu fais ce que tu veux, donc généralement du code crade ou lorsque tu modifies une classe tu dois regarde les autres classes qui l'utilise pour ne rien casser. Alors qu'un object doit faire ça vie seul et être un indépendant pour pouvoir justement modifier facilement une classe dans un code de 100k lignes sans soucis.


RE: Compass : East Oriented - niahoo - 05-06-2015

Citation :J'ai justement pas mis de typehint car tu ne veux pas de askGoldByBeggar(Beggar $beggar)
Et je montre les problèmes que ça soulève, tu dois coder avec une doc et tu ne sais pas tous les types d'objet avec lequel le Hero peu travailler.

Donc pour utiliser Hero tu dois lire le code de la classe ou lire une doc, c'est pas du tout la bonne façon de programmer.
Normalement tu lis juste l'interface et tu es souple et je peux ajouter une classe Women et je sais direct que Hero ne l'a gère pas.

Je suppose que tu réponds à Xenos. Bon, pour résumer un peu, en gros pour pouvoir communiquer avec du code écrit façon East, il suffit d'implémenter les interfaces avec lesquelles le code sait communiquer.


RE: Compass : East Oriented - niahoo - 05-06-2015

Citation :en West tu fais ce que tu veux, donc généralement du code crade ou lorsque tu modifies une classe tu dois regarde les autres classes qui l'utilise pour ne rien casser.
.

Heuuu je vais dire un truc gamin mais prends pas ton cas pour une généralité ... Fondamentalement ça ne change rien, un objet va faire sa vie de son côté puisque il est encapsulé dans son espace propre. Non parce que dans ton exemple, giveGold si c'est pas un setter moi je pige que dalle.


RE: Compass : East Oriented - srm - 05-06-2015

Foisonnement de méthode...
OK.

C'est quoi le plus simple à modifier ou lire :

class Conan implements Hero
{
    public askGold($object)
    {
        if ($object instanceof Beggar) {
            $object->giveGold($this->gold/2);
        }
        
        if ($object instanceof Kid) {
            $object->giveGold($this->gold);
        }
        
        if ($object instanceof Women) {
            $object->giveGold($this->gold * 10);
        }
    }
}

Donc :

class Conan implements Hero
{
    public askGold($object);
}


Ou :

class Conan implements Hero
{
    public function askGoldByBeggar(Beggar $beggar)
    {
        $beggar->giveGold($this->gold/2);
    }

    public function askGoldByKid(Kid $kid)
    {
        $kid->giveGold($this->gold);
    }

    public function askGoldByWomen(Women $women)
    {
        $women->giveGold($this->gold * 10);    
    }
}

Qui donne :

class Conan implements Hero
{
    public function askGoldByBeggar(Beggar $beggar);
  
    public function askGoldByKid(Kid $kid);

    public function askGoldByWomen(Women $women);
  }

Et donc 100% de ton code repose sur des interfaces.
Donc foisonnement de if vs méthode avec interface.
Il n'y a pas photo. Le second est beaucoup plus safe.


RE: Compass : East Oriented - niahoo - 05-06-2015

Non mais ça d'accord, moi je suis d'accord. Mais quel rapport avec East/West ? là c'est un choix d'écriture, ben ok, c'est compatible à la limite donc osef.