Bonjour,  
 
Je travaille sur un petit jeu de foot en php/mysql. Je me débrouille en PHP mais je ne suis jamais passé à la programmation orientée objet, et je me dis que c’est peut-être l’occasion.  
 
Imaginons donc une rencontre entre 2 équipes. Je pensais faire :
 
- Une classe « equipe » avec des statistiques propres à l’équipe que je ne détaillerai pas ici pour être plus clair. J’ai donc 2 instances, une pour chaque équipe : $equipe[0] et $equipe[1].
 
- Une classe « joueur » avec les statistiques personnelles des joueurs : vitesse, fatigue, précision etc… ainsi que son poste sur le terrain (défenseur=0, attaquant=1…), son statut (en jeu=0, expulsé=1) et une référence à son équipe (0 ou 1). Pour les instances, il y en a autant que de joueurs : $joueur[0]… $joueur[21].
 
Jusque là, ça me paraissait cohérent. Mais à l’utilisation, j’ai un peu de mal sur 2 points :
 
- J’aimerais avoir un tableau contenant les clés de tous les joueurs (hors expulsés), trié par un attribut personnel, disons ici la fatigue : ($joueur[]->fatigue).  
 
- J’aimerais également connaître le défenseur (hors expulsé) le moins fatigué d’une équipe.
 
Ce genre de chose est fait vraiment très régulièrement dans le match, et avec différentes variables, j’aimerais donc trouver quelque chose de rapide et réutilisable efficacement.
 
J’avais réussi à faire tout ça sans programmer en objet, mais je voulais quelque chose de plus clair. Et là, mon code commence à devenir du n’importe quoi, je copie des tableaux dans tous les sens pour les trier, et je me demande si je n’ai pas fait fausse route dès le début avec ces classes. Qu’en pensez-vous ?
 
Merci.

Pour la liste des joueurs expulses, pourquoi ne pas creer une methode
$equipe->getExpelledPlayers(); ( avec pourquoi pas en parametre le champ selon lequel on trie le tableau ).
 
J'imagine que ta classe Equipe contient un tableau de Joueurs. Dans ce cas la methode est extremement simple, elle itere sur le tableau et si le joueur est expulse, l'ajoute au tableau du resultat.
 
Bon j'ai fait ca vite fait ya surement des erreurs mais c pour te donner l'idee.
 
Dans ta classe Equipe :

Si je comprends bien, tu verrais un truc comme ça  ?
 

Moi je te conseil de passer en francais completement ou en anglais completement dans la nomination de tes méthodes / attributs, parce que les getFatigue et isDefensor ça irrite je trouve...

 
c'est une question d'habitude
 
sérieusement, le problème c'est que let préfixes set et get sont des normes.

Je note, mais j'avoue que pour le moment, cela m'importe peu. Budlite m'a proposé des fonctions (merci d'ailleurs), je cherche seulement à savoir si la structure, dans mon cas de figure, est correcte. Qu'en pensez-vous ? (notamment d'instancier la classe joueur dans la classe equipe, car je ne suis pas sûr que Budlite voulait dire ça).  

 
Ouais en gros je vois ca comme ca.
Une equipe est composee de plusieurs joueurs, donc un attribut de Equipe doit etre un tableau de Joueurs.
 
Et sinon toute petite correction

est suffisant    

Salut,
 
Moi en général, dans une fonction comme addFatigue, je colle un return $this->fatigue à la fin.
Même si on peut dire que c'est pas vraiment sémantique et tout et tout, je vois que c'est une pratique courante dans certains langages comme Ruby (et il me semblerait que Python fasse pareil) et je dit que c'est vachement pratique

Ben en ruby c'est pas une "pratique" ( au sens ou c'est toi le developpeur qui le met), c'est juste le language qui le fait automatiquement pour toi.

Dans le addFatigue j'aurais plutôt tendance à renvoyer this perso, ça serait largement plus pratique

Pour pouvoir enchainer les commandes ?
genre

Je ne vois que cet interet, y en a t il d'autre ?

Yen a pas d'autre, mais c'est super pratique. Alors que renvoyer la valeur, franchement...

Je pense pareil

C'est bien ce que j'entendais.. Si j'avais voulu dire que c'était une pratique que les dev ont, ça pourrait être pareil dans tous les langages..

Concernant le fait de retourner $this ou la valeur ... C'est un choix :

En l'occurence dans ton exemple c'est pas un choix du tout, juste le comportement par défaut du langage qui est de retourner le résultat de la dernière expression évaluée.

T1 mais je dois mal m'exprimer (ou alors vous comprenez tout de travers).
Je voulais dire que c'est le choix de Ruby de retourner la dernière expression, et non pas $this comme tu l'aurais fait. Il me semble d'ailleurs que Python ait fait le même choix non?
 
De plus c'est un choix que je trouve assez judicieux, parce que comme ça, si tu veux savoir combien de fatigue a un joueur après lui avoir ajouter X, tu peux le faire en 1 coup..

Renvoyer this/self est un choix qui ne peut être fait qu'au cas par cas, dans la mesure où ça n'a pas de sens en dehors des méthodes.

Non, Python demande un retour explicite, sinon il renvoie None (/null/nil/whatever).

Franchement, perso j'aurais collé un attr_accessor :fatigue et baste.

function isDefensor() {
  return $this->poste;
}

 
est suffisant  

Certes, mais si tu sais que tu vas souvent devoir ajouter de la fatigue à un joueur (par exemple s'il subit un tacle), et que donc tu vas le changer s'il a plus que X de fatigue, ça peut être pratique de faire un :

Alors que sinon ça aurait demandé une ligne de plus (d'abord faire le add_fatigue, puis appeler l'accessor) ... Mais bon au fond les deux ont du sens ...
et pis ça aide pas des masses l'auteur du topic de savoir si Ruby et Python font ça ou pas (à part p-e de se rendre compte qu'au lieu d'écrire son site en PHP (en tentant de l'écrire OO) il aurait pu choisir un langage qui est OO de base)

Non mais avec un attr_accessor le add_fatigue dégage hein, il sert plus à rien

Faut voir dans le contexte de l'appli ..
Par exemple si la fatigue ne peut jamais diminuer (à part être remise à 0 entre 2 match), je trouve que ça a pas beaucoup de sens de faire un attr_accessor.
Je ferais un add_fatigue + attr_reader :fatigue

Dans ce cas tu crées une property avec une vraie méthode en writer
 
Non parce que ton add_fatigue, si tu lui passes un nombre négatif sans checker il va diminuer la fatigue hein

Mouais bof je suis pas convaincu .. Mais de toutes façons on s'en fout  
 

Pas convaincu de quoi exactement

attr_reader :fatigue
def fatigue= fatigue
    @fatigue = fatigue unless fatigue < @fatigue
end

Pas convaincu que ce soit beaucoup mieux. Me semble que les 2 approches sont valables

Merci pour vos réponses. Mais pour ce qui concerne le ruby, j'avoue que cela ne m'intéresse pas.  
Par contre, avec ce modèle, je reviens à la question initiale. J'aimerais obtenir régulièrement un tableau de tous les joueurs (des deux équipes donc), avec en clé l'id du joueur (référence à l'objet joueur en fait) et en valeur un critère défini trié (fatigue par exemple, mais il y en a beaucoup d'autres). Est-ce que cette structure est vraiment adaptée ? Parce que dans le cas présent, si je ne me trompe pas je dois reformer un tableau à partir des deux tableaux ($equipe[0]->joueurs[] et $equipe[1]->joueurs[]). Y a-t-il plus simple ? Merci à vous.

Bah tu peux créer un tableau joueurs à partir des 2 autres ayant comme index l'ID du l'utilisateur et comme valeur la valeur en question, après tu fais un sort et c'est bon.. Sinon si tu as déjà à portée de main un array contenant tous les ID des joueurs, tu peux faire une requête SQL sur ces ID avec un ORDER BY fatigue