P.o.o. >> On S'y Met ? :)

Le __autoload permet d'inclure la classe au moment de son utilisation. Si tu fais un new Objet() et que la classe n'existe pas, php va tenter de la charger avec __autoload.

Haaaaaaaaaa.... et pour mes 3 classes, vous avez une idée d'uen bonne organisation ?

Pour moi, la classe Personnage doit être une classe mère. Elle utilisera éventuellement des objets de la classe Account lorsqu'il s'agit d'un personnage joueur, mais lorsqu'il s'agit d'un pnj ce sera inutile.
De la même façon Account utilisera un objet de la classe Session lorsqu'il s'agit du compte du joueur courant, mais pas lorsqu'il s'agit de manipuler le compt d'un tiers joueur.

Toutes ses classes ne doivent pas s'étendre, mais simplement "s'utiliser" selon moi.

Un Account *peut/doit être attaché* à une Session, mais un Account *n'est pas* une Session.
Comme dans l'objet Voiture, qui hérite naturellement de Vehicule (puisqu'une Voiture *est* un Vehicule), mais qui ne va pas hériter de Roue, il va simplement avoir un ou plusieurs paramètres de la classe Roue
La Session est une roue de l'Account, mais pas sa généralisation (c'est pour ça que j'emploie le terme "générique" souvent en parlant de la classe mère, une classe fille étant une spécialisation de la classe mère, en remontant de fille vers mère on doit pouvoir parler de "généralisation", ce qui est bien le cas en remontant de Voiture vers Vehicule, mais pas de Account vers Session ni de Personnage vers Account).

ce que je retiens de tout ça, c'est que les classes sont très utiles quand on commence à avoir beaucoup de code pour mieux structurer le tout... grace à vous et à toutes ces infos, je commence à mieux en comprendre l'intérêt. Et comprendre qu'il me reste beaucoup de chemin à parcourir...
merci

Content que mes questions soient suffisamment générales pour être utile à plusieurs

Je viend d'apprendre l'utilité des trucs STATIC, et ca répond à mon interrogation au sujet de bien des trucs en fait.

Edit:
J'en profite pour rapeller que si vous avez de l'expérience en objet, et que vous êtes en recherche de projet, votre collaboration serait apprécié pour CyberCity côté notion objet.

Question ... de base:

La je suis très conscient que les 3 dernières lignes ne sont pas dans un objets...
Je n'arrive pas encore à rendre tout 100% objet (j'y travaille cependant), donc je peut pas faire une sorte de parent::account->siteSkin .

Existe-t'il une autre facon d'accéder à la variable ?
>> En la mettant static
>> >> Oui mais la classe account est instanciée (et éventuellement il y en aura d'autres probablement) huhu !



... Sinon je suis content car a priori ma page d'accueil passe de 0,009 sec à 0,005 sec à générer (ce qui représente quand meme un gros %... j'ai hate de voir sur les vrai grosses pages) (Sur la version actuellement en ligne: 0.06 sec ... plus de 10x plus rapide )

Pourquoi ne pas le passer en paramètre ?

Ou carrément en attribut (selon l'importance de la persistance de la variable au sein de l'objet en fait) ?

je peux aider pour mettre les tests unitaires sur pied via SimpleTest, mais pas avant la mi-octobre.

A+

Pascal

Ho, ca c'est intéressant, ca signifie que, par exemple, pour ma classe Session et Account, les deux ont le droit de contenir 'username':

Account parceque username est le nom du compte
Session parceque cette classe fait le lien entre le # session et le compte.

(L'air de rien en 3j j'en ai appris des trucs ;p)



-----
Pascal: Merci pour ton offre d'aide, mais qu'est-ce que 'des tests unitaires' ?

les tests unitaires...

en gros, c'est écrire un code pour tester les méthodes des classes.

telle methode vérifie le mail. ok, dans ce cas on lui balance un mail en entrée, et on vérifie TRUE en sortie; on lui balance une chaine quelconque, et on attend FALSE en sortie.

avec les tests unitaires, chaque fonction de base est validée et testable à l'infini;
on peut faire évoluer le code et éviter les régressions ( bugs dûs à des modifs dans le code )
on détecte les bugs à la source;
en écrivant un test, on écrit un exemple d'utilisation de l'objet

quelques liens:
http://pascalduverge.canalblog.com/ ( un blog où épisodiquement je parle d'informatique, dont les tests unitaires )
http://onpk.net/php/simpletest/ ( La doc de référence en français )

A+

Pascal

Hum, pour le moment mes besoin sont plus d'arriver à créer 'optimalement' les trucs à tester que de les tester...

Je garde ton offre en tête pour plus tard par contre. Merci !

la création et les tests sont intimement liés... c'est pourquoi je te conseille defaire des tests dès qu'une classe est "prête".

Bon courage!

A+

Pascal

optimal <--> optimisé + stable --> stable --> testé
CQFD

Ouais je suis d'accord, sauf que comme je commence, je créer une classe, puis quand j'en créer une autre, je me rend compte que la première était incorrecte et je la modifie... ( bah ouais, faut commencer .. )

la méthode est:
_ je crée une classe, elle doit faire ça, ça et ça
_ je vérifie qu'elle fait ça: valeurs par défaut, enreg. en DB ( ajout, modif, suppr...), création de fichier ...
_ tant que les tests vérifiant ça, ça et ça ne sont pas passés, on ne code rien d'autre
_ si une modif ( ajout de fonction, optimisation, modif d'une autre classe ) fait planter un test, on trouve pourquoi et on répare

c'est cool car:
_ ya moins de bugs
_ on est "sûr" de son code
_ on capitalise: les tests vont servir pendant toute l'évolution de l'application

c'est chiant car:
_ desfois les tests sont durs/chiants à créer car la modélisation est pas top
_ on passe du temps à écrire des tests ( ce n'est pas l'application, donc d'une certaine manière c'est du code "non productif", mais c'est faux )
_ on a moins de bugs, et moi les bugs, j'adore leur mettre une raclée. là, il reste les bugs suivants: 1. truc non testé; 2. bug de la mort qui tue

well, have fun!

A+

Pascal

Ouais, sauf que je suis même pas encore rendu à ce niveau moi...

Exemple: je suis pas encore fixé si je vais mettre ma variable 'username' dans la classe Session (l'utilisateur authentifié) ou dans ma classe Account.

Et je suis tellement pas encore fixé sur le sujet que je suis rendu à me demander si ma classe account est réellement utile pour le compte principale ou si je vais juste m'en servir pour les listes de comptes dans la gestion des comptes.

^^ Tu commence à comprendre quand je dis que c'est encore trop tot pour créer des 'tests '? ;p

Coucou,

Je rajouterais encore un truc extrait de l'extrem-Programming.
Lorsque tu as créé tes méthodes de test, et que tout est OK, ne les supprime pas.
Laisse toi une fonction qui permet de tester toutes tes classes. Ca ne prend pas de place dans un fichier, et en plus c'est super pratique.

Grosso-modo, il faudrait une fonction de test MINIMALE par classe, le mieux étant une fonction de test pour chaque méthode. Cela dit, ce type de programmation concerne les programmes volumineux et je ne sais pas si tu vas t'y engager directement.

Bonne journée à toi !

kéké.

Et comment est-ce que vous créez des fonctions de test pour les méthodes fesant appel à l'aléatoirisme ?
(exemple: fonction d'attaque qui conprend:
- Jet de dé sur les compétances d'un joueurs
- Prise en compte des effets de drogues
- Prise en compte d'une arme
- Prise en compte des munitions de l'arme
- Prise en compte des défense de l'oposant
- Prise en compte des compétances de l'oposant
)

... Tout va pour dire que ce genre de fonction se base sur des éléments extérieurs qui ne peuvent pas se "passer en paramêtre" je vois mal comment une seule fonction peut tester ca. :-\

SimpleTest permet l'utilisation de "mocks", afin de remplacer les méthodes d'une classe par un résultat arbitraire fixe. Du coup une fois que ta fonction "jetDe($nbFaces)" est testée et validée (tu fais 1000 jets et tu vérifies qu'il n'y a pas de résultat en dehors de l'intervalle par exemple), tu la remplaces par un "mock" (en fixant le résultat) lorsque tu testes des méthodes en dépendant.

Cela dit c'est un point que je ne maîtrise pas car je ne l'ai pas expérimenté concrètement.

Mouais, honnêtement je suis pas contre le principe, mais très loin d'être rendu là dans mon évolution pour le moment

Note: J'ai finalement décider que ma classe Session regrouperais les informations de session, et que la classe Account servirait juste pour les liste de personnages et les actions liées à la gestion des comptes.

Vous m'avez dit précédemment qu'il était préférable, dans mon cas, de créer plusieurs classes au 'même niveau' et d'éviter l'héritage.

Si j'ai:

Comment est-ce que la classe session est-elle supposée accéder à la classe perso ?
(et vice versa)

Ps.: Je suis au courrant que je pourrais passer la classe $session au constructeur de la classe Perso, mais ca me permet qu'un contrôle dans une seule direction



Note: Actuellement, cet exemple de code se trouve directement dans un fichier PHP, pas dans une classe 'principale', donc, je ne peux pas faire parent::session->sessId à partir de la classe Perso par exemple.

Auto réponse à la note: Si je créer une classe principale justement, je vais me retrouver à ce que 100% de mes autre classe hérite de cette classe 'principale', est-ce une bonne facon de résoudre mon problème / bonne facon de faire.

Merci encore pour votre aide ! ( sérieusement en objet je réalise que j'ai encore beaucoup de trucs à apprendre ... )

La vraie question est : pourquoi diable Session devrait accéder à Personnage ?
Définis précisément ce que représente la classe Session pour toi, car moi je ne l'ai développée que comme une surcouche pour la gestion des sessions (avec un session_start() dans le constructeur, et un accès à $_SESSIOn via les méthodes).

Ensuite même Personnage ne devrait pas avoir accès à Session. Un personnage n'est qu'un élément du jeu. Plus particulièrement un Personnage non joueur n'a pas à accéder à une session (et Personnage étant la généralité, il représente les pj et les pnj, donc n'a pas à faire référence à Session).

C'est Joueur (ou Account chez toi apparemment) qui doit utiliser Session, mais pourquoi Session devrait utiliser Joueur ?

Plus important que tout, plus important que code, plus important que tester, il faut surtout modéliser

Hum, j'y ai repensé et j'ai créé une classe Main qui elle s'occupe de charger Session, Account, Template, et éventuellement le Perso et Page (pour les actions).

Cependant j'arrive à un problème:
Je n'ai qu'un seul objet de type Main, Session et Account. Et je cherche à ce que ma classe Session (qui détecte quel utilisateur est connecté) puisse définir le champs Account::user;

Hors je n'y arrive pas SAUF si je met les TROIS classes en static (C'est à dire toutes leurs méthodes et variables).
C'est pas énormément con ca ?

Donc la, la question que je me pose, c'est comment est-ce que, à partir d'une méthode de ma classe Session, je peux modifier une valeur d'un objet de ma classe Account ?

J'ai essayé ceci:
Main::account->user = 'le_user';

mais ca ne fonctionne pas.
Je vois partout dans mes bouquin et sur le net que ca fonctionne pour apeller une méthode, mais il semble que ca soit impossible pour une variable, même de type Public. C'est moi qui est con ou ... ?

Non tu n'as juste pas bien intégré le concept d'objet, j'ai l'impression que tu mélanges instances d'objet, méthodes statiques, et variables globales ^^

Une variable globale c'est une variable qui est accessible partout
Une instance d'objet c'est un objet d'une classe ($instance = new ClassTruc())
Une variable static c'est une variable qui sera unique parmis toute les instances et qui n'a d'ailleurs pas besoin d'être instancié pour être utilisée.

Pour mon erreur, je l'ai réglé en déclarant mes variables d'instanciation de mes classes en static.

Et pour accéder correctement aux variables, il me manquait mon $:
Main::$account->user;


naholyr >> Vérifie tes PvMSG.