10-10-2017, 04:20 PM
[ P***, il m'a battu sur la longueur de post! :O ]
Je suis d'accord sur le fait que l'instance de "Personnage" n'a aucun sens vu que tous les persos, dans ces jeux, ont les mêmes comportements (c'est un mélange entre comportements différents, qui appelle plutôt de la POO en effet, et manipulation de données, qui devient d'une simplicité déconcertante et d'une fiabilité à tout épreuve quand on se passe de POO). En revanche, dans les deux cas, il n'y a rien à stocker en session, ce serait même malsain car cela mélange les rôles de la session (Authentication) et de la BDD (Data storage).
Oui, tu peux te servir de la session pour du Data Storage, à la condition qu'il n'y ait pas besoin d'interaction entre les sessions. Mais si t'as besoin d'interaction, et c'est souvent le cas, je trouve que c'est une très mauvaise pratique (niveau accès concurrents, fiabilité du stockage, et mises à jour des structures, c'est se faire chier pour rien).
Hum... T'es pas le premier à dire "en terme de perf, bof" dès qu'on parle de SQL (ou autre stockage, mais je prendrai celui-là). Temps de connexion OVH: 1ms. Temps d'execution d'une requête renvoyant 2000 lignes de data (id, x, y, z, caseType de mémoire): 3ms. Donc, non, c'est pas "lent". C'est juste fiable et propre, et c'est ce qu'il faut utiliser. On ne se sert pas des sessions comme d'un "cache qui économise les requêtes SQL". Si tu veux du caches, tu prends un composant de cache client (ie: un cache "côté PHP") séparé de la session (POO ou pas).
Ton exemple de tourelle est, là, un cas typique de POO en revanche.
La factorisation ne sert qu'à fusionner les éléments de même sémantique. S'il est logique que deux entités aient (et auront "toujours") le même comportement, alors oui, tu factorises. En revanche, s'il n'y a pas fondamentalement de logique à ce que les deux entités aient le même fonctionnement, là, tu "copies/colles" (et souvent, t'y verras des variations). Sinon, à tout merger, tu ne pourras plus rien toucher tant les ramifications du moindre truc partiront dans tous les sens. On retombe surtout sur le point essentiel du propos: un périmètre bien délimité pour chaque composant du projet. C/C ou factorisation deviennent mauvais quand ils cassent cette règle.
"Make it work", c'est la 1ere règle. Après, "Make it right". Après "Make it fast". Le but est bien de remplir le besoin en premier lieu, et après, de s'amuser au peaufinage et fignolage interne (qui se fait très bien si, justement, tu respecte la notion de "périmètre hermétique pour chaque feature").
Nombre de créateurs sont passés ici, voulant faire du "bien et joli et propre parce que c'est mon projet perso et j'suis pas au boulot"... Je ne suis pas sûr que beaucoup d'entre eux aient sorti quelque chose (et encore moins le tenir dans le temps).
Je brefise donc moi aussi: le plus important pour moi est d'avoir des périmètres bien délimités pour chaque feature, et d'éviter les codes qui traversent toute la stack. Cela permet une maintenance simple et un refactoring simple en limitant les ramifications des modifs (qu'on soit POO ou pas).
Je suis d'accord sur le fait que l'instance de "Personnage" n'a aucun sens vu que tous les persos, dans ces jeux, ont les mêmes comportements (c'est un mélange entre comportements différents, qui appelle plutôt de la POO en effet, et manipulation de données, qui devient d'une simplicité déconcertante et d'une fiabilité à tout épreuve quand on se passe de POO). En revanche, dans les deux cas, il n'y a rien à stocker en session, ce serait même malsain car cela mélange les rôles de la session (Authentication) et de la BDD (Data storage).
Oui, tu peux te servir de la session pour du Data Storage, à la condition qu'il n'y ait pas besoin d'interaction entre les sessions. Mais si t'as besoin d'interaction, et c'est souvent le cas, je trouve que c'est une très mauvaise pratique (niveau accès concurrents, fiabilité du stockage, et mises à jour des structures, c'est se faire chier pour rien).
Hum... T'es pas le premier à dire "en terme de perf, bof" dès qu'on parle de SQL (ou autre stockage, mais je prendrai celui-là). Temps de connexion OVH: 1ms. Temps d'execution d'une requête renvoyant 2000 lignes de data (id, x, y, z, caseType de mémoire): 3ms. Donc, non, c'est pas "lent". C'est juste fiable et propre, et c'est ce qu'il faut utiliser. On ne se sert pas des sessions comme d'un "cache qui économise les requêtes SQL". Si tu veux du caches, tu prends un composant de cache client (ie: un cache "côté PHP") séparé de la session (POO ou pas).
Ton exemple de tourelle est, là, un cas typique de POO en revanche.
La factorisation ne sert qu'à fusionner les éléments de même sémantique. S'il est logique que deux entités aient (et auront "toujours") le même comportement, alors oui, tu factorises. En revanche, s'il n'y a pas fondamentalement de logique à ce que les deux entités aient le même fonctionnement, là, tu "copies/colles" (et souvent, t'y verras des variations). Sinon, à tout merger, tu ne pourras plus rien toucher tant les ramifications du moindre truc partiront dans tous les sens. On retombe surtout sur le point essentiel du propos: un périmètre bien délimité pour chaque composant du projet. C/C ou factorisation deviennent mauvais quand ils cassent cette règle.
"Make it work", c'est la 1ere règle. Après, "Make it right". Après "Make it fast". Le but est bien de remplir le besoin en premier lieu, et après, de s'amuser au peaufinage et fignolage interne (qui se fait très bien si, justement, tu respecte la notion de "périmètre hermétique pour chaque feature").
Nombre de créateurs sont passés ici, voulant faire du "bien et joli et propre parce que c'est mon projet perso et j'suis pas au boulot"... Je ne suis pas sûr que beaucoup d'entre eux aient sorti quelque chose (et encore moins le tenir dans le temps).
Je brefise donc moi aussi: le plus important pour moi est d'avoir des périmètres bien délimités pour chaque feature, et d'éviter les codes qui traversent toute la stack. Cela permet une maintenance simple et un refactoring simple en limitant les ramifications des modifs (qu'on soit POO ou pas).