Blog : POO - Développement d'un application de suivi de score au tennis

Bonjour à tous,

faisant suite à une discussion sur le forum PHP de DVP relative au développement d'une application de suivi de score d'une partie de tennis, et voyant la dérive du code source vers une casserole de spaghettis ;), je m'étais dit que cela pouvait être l'occasion de résoudre cette problématique réelle avec une approche 100% objet.

Je suis donc parti d'une feuille blanche et j'ai essayé de faire au plus simple.
Pour aborder cet billet, il va quand même falloir ne pas être trop néophyte en matière de programmation PHP et travailler en PHP 7+.

Bref, si vous avez des remarques n'hésitez pas à m'en faire part afin que je puisse améliorer ce travail (qui m'a quand même claqué un bon paquet d'heures).

C'est par ICI que cela se passe :ccool:

rawsrc

Article très intéressant :ccool:

Il y'a quelque chose qui me chagrine :
La classe Set , reçois en paramètre une Partie. Le problème c'est que Set est déjà contenu dans une Partie. On est pas loin d'une référence circulaire. Idem pour Set et Jeu
C'est d'autant plus génant que la Partie n'est pas utilisé dans Set mais transmise à Jeu pour récupérer l'id du joueur.
Je n'y est pas réfléchie particulièrement , mais je pense qu'il est possible de faire mieux. Peut être en gérant le score au niveau de la partie avec une notification des set/jeu via un observer à chaque fois qu'un point arrive par exemple.

salut grunk,

ta remarque est pertinente mais c'est de l'initiation à la POO, si on commence a s'embarquer dans les Observer, références circulaires et autres joyeusetés (design patterns) c'est cuit.
C'est un coup à perdre totalement l'auditoire. Je vise les développeurs qui ont du mal à voir l'utilité de la POO et surtout je voulais montrer qu'il était possible d'utiliser les principes basiques de la POO pour modéliser et résoudre une problématique réelle.

Il faut déjà bien comprendre les principes de base avant d'aller plus loin, comme t'as pu le constater, le code est redondant, pas optimisé pas beau ;)
Le but c'était juste de poser les premier éléments et après si les lecteurs y voient un intérêt, ils iront d'eux-même chercher à progresser.

Pour ce qui est du suivi des scores, il y a des tas de manières possibles de le faire : même dans la classe Joueur.

Bonjour,

Je ne suis pas développeur PHP.

Je suis d'accord avec grunk sur les problèmes de référence circulaire, mais on peut les résoudre sans passer par un observateur. Il suffit de passer moins d'informations à certains constructeurs et d'adapter du code en conséquence.

Par exemple, actuellement, la classe Jeu n'utilise vraiment la classe Set que pour récupérer les identifiants des joueurs :

Code:

---

1 2 3 4

$scores = [ $set->partie()->joueur1()->id() => 0, $set->partie()->joueur2()->id() => 0 ];

---

À la place, la classe Jeu pourrait ne connaître que les identifiants des joueurs sans connaître la classe Set.
Ou alors, en changeant plus de code, la classe Jeu pourrait même ne pas connaître les identifiants des joueurs et laisser le code appelant savoir à quels identifiants de joueurs correspondent le joueur 1 et le joueur 2.

De même, la classe Set n'a pas besoin de connaître la classe Partie. Le code de la classe Set se contente de stocker une instance $partie et, en dehors du constructeur et de l'accesseur partie(), elle ne l'utilise nulle part.

Cela évitera le problème de la banane, du gorille et de la jungle que Joe Armstrong reprochait aux langages objets :

Citation:

---

Envoyé par Joe Armstrong

I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.

---

Ici, la banane correspond à la classe Jeu, le gorille à la classe Set et la jungle à la classe Partie.

Salut Pyramidev

Citation:

---

Envoyé par Pyramidev

Je ne suis pas développeur PHP.

---

T'inquiète, pas besoin d'être développeur PHP pour parler architecture et modélisation.

Je conçois parfaitement tes remarques mais le but de ce billet c'est de résoudre un problème réel grâce à une pensée objet basique et en dehors de toute considération architecturale trop optimisée/avancée, relative à l'orienté objet axé sur les bonnes pratiques. Je vois que cela offense les puristes mais bon, il faut bien débuter un jour et généralement quand tu débutes tu évites de t'embarquer trop vite dans l'inconnu.

Inévitablement, celui qui s'y frotte devra un jour s'intéresser aux finesses de la pensée objet et à ce moment il pourra re-modéliser ce petit jeu. :ccool:

Bonjour,

j'ai procédé à une mise à jour du code des vues de ce billet afin de le rendre compatible avec la dernière version de PhpEcho.

J'ai également mis à jour le ZIP téléchargeable à la fin du billet contenant tout le code de l'exemple.

Le reste n'a pas bougé d'un iota.

@++

rawsrc