[Résolu] Retours multiples de fonction : tableau, tableau associatif, ou objet ?

[Ter Rowan]

ah ben je dois être à plus de 1000 lignes (en comptant du commentaire) mais je pense être factorisé, certainement trop (probablement mal) car j'arrive à une usine à gaz mais bon pour donner un exemple :

la classe qui gère les compétences :

include_once('action/ModRootAction.php');

include_once(REP_PARAMS.'ParamAction.php');





/* modCompetence permet de 

**

**	- connaitre les compétences nécessaires

**	- modifier les compétences en fonction de l'attitude

**

*/



class modActionCompetence  extends modRootAction

{



    public function getCompetences()

    {

        return $this->_contraintes;

    }

    

    public function ControleCondition($acteur, $conso, $idComp,  $valeur)

    {

 /**

 * Calcule les pénalités (ou bonus) d'une condition. 

 * @author Lionel SORBIER

 * @param  acteur = un participant à l'action

 * @param  conso = le type de consommation

 * @param  idComp = l'id de la competence

 * @param  valeur = la valeur de référence

 * @since 1.0

 * @return    le bonus/malus calculé

 */

    	if ($conso !=PRESENCEINDIVIDUELLE)

    	    return array('malus' => 0,'raisons' => 0);

    

    	$modif = 1.0;

    	/* impact des attitudes */

        $att = $acteur->getModule('Attitude');

        if (!($atts = $att->getAttitudes()))

            $atts = array();

            

    	foreach($atts as $attitude)

    	    $modif *= paramAction::$_compModif[$attitude];

    

    

    	$comps = $acteur->getModule('Competence')->getValeurs();

    

    	return array( 'malus' => paramAction::$_compBase + $valeur - $comps[$idComp]*$modif, 'raisons' => 0);

	   

    }

}

sauf que j'ai pas encore modifier le retour via un objet ^^

grosso modo, j'ai une classe classAction qui porte l'algorithme global :
contrôle des participants, calcul de la réussite, réalisation et consommation (énergie, etc..)

cette classe possède 1 à plusieurs "modules" (genre compétence) fonction de l'action. Pour les étapes contrôle et consommation précédemment citées, elle boucle sur les modules et consolide les résultats

chaque module hérite de modRootAction qui est commun à tous les modules et porte 60% à 80% du code "efficace" du module (genre pour compétence, la seule chose non factorisée est la récupération de la compétence, et l'impact de l'attitude du personnage sur la compétence : un personnage "pressé" à un malus par rapport à un personnage "soigneux")

tout allait très bien jusqu'à ce que je traite les modules environnement et outil. En effet contrairement à une compétence, le contrôle sur un outil se fait à plusieurs niveaux :
est ce que l'outil est présent (facile)
est ce que l'outil est utilisable, a t il assez d'énergie/carburant (facile)
est ce que le personnage sait utiliser l'outil, et avec quelle difficulté (plus difficile, ça veut dire, vu que j'ai factorisé ^^, faire appel à un autre module)

je m'en sors pas trop mal mais ça nécessite un peu de charge


à noter, ma nomenclature à moi : les mots clés en anglais (get,by, mod, root...) , les mots "métier" en français (je voulais tout faire en anglais au début, c'est plus court à écrire, mais mon niveau n'est pas suffisant pour comprendre rien qu'à la lecture ce que font mes méthodes au bout de deux mois ^^

[srm]

Dans l'exemple donnée ça sert à quoi raison exactement ?
Concernant la nomenclature de nommage, met au moins tout en camelCase, là tu mets le nom de tes méthodes avec des majuscules

[Ter Rowan]

raisons, c'est pour les raisons de refus

l'action est impossible à cause :
je ne suis pas au bon endroit,
je n'ai pas l'outil,
je n'ai pas la connaissance de l'outil,
la somme des malus rend l'action impossible (même si unitairement, tout est ok)


pour le camel Case , il y est ^^ variable en minuscule, classe en minuscule, fonction en méthode en majuscule, sauf si racine est un mot clef ( is, set get).

J'avais tout mis en CamelCase au début, mais un peu moins lisible à ma lecture (après tout getToto, c est "donne moi la valeur de toto" donc une variable donc en minuscule :p )

Aussi débile que la langue française quoi ^^

---

pour en revenir à l'exemple donné, il n'y a aucune raison possible d'éliminer un personnage de l'action

mais par exemple pour caractéristique:

    function ControleCondition($acteur, $conso, $idCarac, $valeur)

    {

 /**

 * Calcule les pénalités (ou bonus) d'une condition. 

 * @author Lionel SORBIER

 * @param  acteur = un participant à l'action

 * @param  conso = le type de consommation

 * @param  idCarac = l'id de la caractéristique

 * @param  valeur = la valeur de référence

 * @since 1.0

 * @return    le bonus/malus calculé

 */

        if ($conso !=PRESENCEINDIVIDUELLE && $conso != CONSOINDIVIDUELLE)

    	    return 0;



    	$caracs = $acteur->getModule('Caracteristique')->getValeurs();

            $d = $valeur - $caracs[$idCarac];

    	if ( $d > 0)

    	    return array( 'malus' => paramAction::$_MAXPENALITES, 'raisons' => array($idCarac => $d) );

    	elseif ($d == 0)

    	    return array( 'malus' => paramAction::$_caracMalus, 'raisons' => 0);

    	else

    	    return array( 'malus' => 0, 'raisons' => 0);

	   

    }

on a la raison (quelle caractéristique déconne) unitaire. Sachant que dans le module générique, on peut très bien avoir besoin de deux caractéristiques, il faut alors savoir si c'est à cause, d'une ou des deux caractéristiques qu'il y a élimination

[srm]

Donc pour la raison tu devrais jeter une exception

[Ter Rowan]

ben je pense pas

En effet, mon module traite les actions d'un type comme de plusieurs, sur une ou plusieurs séquences:


exemple pour les vieux qui se souviennent de Conan le barbare :

enfant, Conan est fait esclave et doit, avec d'autres enfants faire tourner un puit (en poussant un axe et en tournant en rond)

l'action est de faire tourner le puit
il faut une force minimum pour le faire, normalement (dans le film) deux adultes ou six enfants (et à la fin Conan tout seul, il est tellement fort)

mon système fonctionne pour modéliser cela :

j'ai un groupe de x personnages qui vont pousser (entre 1 et n)

1 tour de puit =
chaque personnage doit avoir l'énergie nécessaire pour pousser
si un personnage n'a pas l'énergie suffisante, il est exclus, mais le processus continue
si la somme de la force des personnages dépasse le seuil, ils peuvent pousser

et on boucle jusqu'à ce qu'il n'y ait plus personne ou que la somme de la force des restants soit trop faible pour faire tourner le puit

pour moi il n'y a pas d'exception. Ce n'est pas un comportement anormal de ne pas faire tourner le puit ou, au bout de 15 tours de s'écrouler parce qu'on est trop fatigué

peut être que je ne comprends pas bien l'exception, mais pour moi c'est plus à utiliser dans le cadre d'un traitement de comportement "anomal"

[niahoo]

Ben c'est ce que je lui disais quelques posts auparavant, mais d'un autre côté ça marche aussi avec les exceptions. C'est une histoire de goût.

[Ter Rowan]

C'est une histoire de goût.

quick & dirty ?

^^

[niahoo]

Non, non, on parlait justement d'erlang dans d'autres posts, c'est une pratique courante dans ce langage qui s'y prette mieux que php, c'est sûr ; ça marche bien en php.

[srm]

Une exception n'est pas forcément quelque chose d'anormal
C'est ici ce que l'on appel dans le monde professionnel "une exception métier".
Càd une exception par rapport au fonctionnement de la couche métier.
Ici ta coucher moteur ou tourniquet, tu as une exception pour dire "hop il tourne plus car il est fatigué"

[niahoo]

Tu ne réfléchis qu'en termes de réussite/échec d'une opération.
Un fonction qui retourne un tuple peux retourner une infinité de valeurs différentes dans la première case, avec des données associées dans les autres cases.