POO, gestion et utilisation

[Dexyne]

Bah j'ai pour le moment ma classe stats avec dedans mes variables (toutes en protected jusqu'à ce que je sache vraiment la différence avec public xD) et j'ai mis mon __constructor avec les différentes variables défini pour leur valeur par défaut sauf que ça ira pas totalement..

J'ai une table qui contient les stats de chaque unité de tous les joueurs.
Mais j'aimerais savoir comment vous organiseriez le code ou vos table parce que dans mon cas j'aimerais "séparer" les unités vivantes et les unités de type véhicules.
Niveau BDD ça change pas grand chose suffit de mettre en NULL ou à 0 ce qui n'est pas existant pour l'autre type d'unité mais niveau des classes si je met des valeurs par défaut ça iras pas pour les 2.
Je peux tout mettre à 0 mais bon ça servirait pas trop, je pourrais via l'héritage changer ou mettre des valeurs pour un type ou un autre mais en fin de compte une unité vivante (ex: guerrier et archer => aucun rapport avec mon projet) n'auront pas les mêmes stats (sauf certaines comme le moral par exemple).
Donc au final est-il préférable de faire une table qui contient les valeurs par défaut de chaque unité ?

Je me paume de plus en plus j'ai l'impression XD. Niveau BDD c'est un peu le bordel là x).

EDIT: j'ai l'impression de me faire encore plus embrouiller là XD
Je voudrais partir simple pour l'instant hein ^^'

[SorenS]

le singleton c'est un principe très sympa, la fonction getInstance contient un évaluation de condition (if quoi) dont on sait pertinement qu'elle donnera toujours le même résultat sauf une seule fois, la première.

comme grosse failure y a pas mieux je trouve !

C'est juste pour être sur que la classe est unique. Je ne vois pas du tout où est la failure...

Sinon un conseil pour faire tes classes, commence par du code simpliste, bourrin, pas optimisé, recopié plusieurs fois à l'intérieux de tes classes.
soigne l'extérieur des classes, leur interface, comment on va faire appel à leurs méthodes (donc notament tout ce qui sera public) (range les protected du côté des privées).
Et quand ça marche, là tu peux revenir à l'intérieur de de ta classe pour la nettoyer, l'optimiser.

Pas d'accord. Faut mieux avancer moins vite mais avec quelque chose de propre que rapido avec du sale code. Tu passeras plus de temps à y revenir dessous que si tu le fais direct

[niahoo]

bof, je préfère de loin avoir des fonctionnalités qui fonctionnent rapidement, pour voir si elles remplissent bien le rôle que j'espérais, voir si l'interface est adéquate, et m'appuyer dessus pour développer d'autres trucs plutot que de faire une fonctionnalité optimisée à donf pendant deux mois pour ensuite me rendre compte que je dois péter une classe en deux et en fusionner deux autres ..

Le gain de temps je le retrouve quand j'ai rapidement une appli qui marche, un bon prototype, et on voit aussi rapidement les erreurs de conception qu'on a faites.

[SorenS]

on parle pas d'optimisation à fond non plus ^^ juste d'un singleton qui t'évitera bien des ennuis ensuite (plus besoin de passer la variable de bdd, ni de la mettre en global par exemple).

Et normalement, ta conception est réfléchie avant que tu ne codes

[niahoo]

Hmm non je ne parlais pas du singleton dans mon paragraphe.

Je disais que quand on attaque la programmation orientée objet, on ne sais pas forcément toujours ou on va. D'ailleurs, la conception est réfléchie, oui, mais ne t'es-t'il jamais arrivé de déplacer une méthode d'une classe à une autre ? Je ne te croirais pas si tu me disais que non de toute façon.

Bref, quand on attaque l'objet on fait des classes un peu pour tout et n'importe quoi, parfois à raison, parfois on va supprimer plusieurs classes car on a pris une mauvaise voie. Ne pas avoir passé 40 ans à coder ces classes évite de se décourager.

Ensuite, un sigleton c'est un design pattern qui tient en 5 lignes donc oui, je ne parlais pas d'optimisation sur le singleton, mais bien de pouvoir créer des objets rapidement, de pouvoir expérimenter un peu.

Enfin, je ne vois pas où se situe le problème dans le fait de passer les objets qui gèrent l'accès BDD en paramètre à d'autres objets. Je pense même que c'est une bonne pratique, et d'ailleurs c'est parfaitement compatible avec l'utilisation du singleton.

Fin bref, 10 millions de développeurs objet, 10 millions d'avis !

[Kihmé]

je vois que tu parles d'une classe stats, son but est la gestion des stats de tes unités si je comprend bien?

Dans ce cas tu n'as pas besoin de cette classe, ta classe Unité contenant les informations est suffisante. Tu vas ensuite dans ta classe Unité implémenter des méthodes qui te renverrons les stats voulus.

Pour les propriétés de tes classes. Tu as le choix entre Public, Private ou Protected.

Une propriété public peut être vu de n'importe où, aucune restriction d'accès.
Une propriété private n'est accessible qu'en travaillant sur une instance de ta classe et en utilisant son getter.
Une propriété protected n'est accessible qu'en travaillant sur une instance de ta classe ou par une instance d'une classe fille (qui hérite de la classe où sont tes propriétés protected).

Dans ta partie model qui contient les classes du style User, Item, Country... Les propriétés sont en private.

Class Player

{

	private $id;

	private $name;

	private $password;

	private $creatures;

	private $trainings;

	

	function __construct()

	{

		$this->creatures=new ArrayObject();

		$this->trainings=new ArrayObject();

	}

	

	public function getName()

	{

		return $this->name;

	}

	

	public function setName($aName)

	{

		$this->name=$aName;

	}

}

[Dexyne]

Où devrais-je donc placer mes stats de base ? Dans une Table de la BDD ? Récupérer ensuite par mes fonction de ma classe (en partie) ?

Dans le code que tu met Kihmé, qu'est-ce ArrayObject() ? J'ai regarder sur php.net mais c'est plein de truc pas compréhensible pour moi è_é. (à part 2-3 que j'ai déjà croiser mais jamais utiliser ou alors sans m'en rendre compte :o)
Je vais voir pour en lire (ou voir) d'avantage sur la POO et essayer de mettre ma classe unités et joueur en place.

Quand faut-il utiliser les classes exactement ? Car je vois que tu met Item par exemple Kihmé ou même Country, je n'y vois pas vraiment quoi y mettre (pour Country surtout) mise à part peut-être la gestion de la carte..

Sinon merci beaucoup pour vos réponses j'arrive à voir un peu plus claire dans le truc.
C'pas encore ça mais bon ça vient petit à petit .

[Kihmé]

En fait, tu vas devoir élaborer ce qu'on appelle un mapping. Les objets utilisés en POO ne sont pas compatible avec les bases de données relationnelles. Ce qu'on fait c'est que la où en procédural et relationnel on avait une table utilisateur on va rajouter à notre application une classe utilisateur. Elle aura comme propriété la même chose que notre table a en propriété. La version la plus basique voudrait que ta classe utilisateur a comme propriété : id, nom, dateNaissance si ta table est sous cette forme UTILISATEUR(#id, nom, date_naissance). A la création d'un utilisateur, dans ton constructeur pourquoi pas, tu ouvres une connexion à la bdd puis applique une requète d'insertion où tu passes en paramètre les propriétés de ta classe. PDO gère ça très bien. Du coup tes setters fonctionneront pareil. Je sens qu'il faudrait que je te fasse un step by step sur un exemple concret, j'ai peur d'être vague et que le théorique ne suffise pas.

Par exemple dans ta classe tu rajoutes un setter afin de modifier le nom.

public function setName($unNouveauNom)

{

     //traitement de connexion à la bdd

     //Connexion à la bdd, puis élaboration de la requete , envoi de la requete.

     $this->name=$unNouveauNom;



}

Pour tes stats, je me dis que ta bdd doit être composée d'une table unité et les caractéristiques de tes unités sont dans cette table chacune en tant que colonne non?
Si c'est le cas, dans ta CLASS unité, tu vas avoir une ou plusieurs méthodes qui vont te renvoyer en sortie la stat issus des traitements des caractéristiques (attributs de la class unité).

Pour l'exemple suivant on oubli pas que les méthodes getDefense() et getVitesse() doivent être dans cette même classe et qu'elles renvoient les caractéristiques qui leur correspondent puisque dans la méthode getDefense() par exemple, on s'est connecté à la bdd et on a récupéré la valeur de la défense par un select defense from unité where id = attribuIdDeLaClass

Class Unité

{

        private $id;

	private $name;

	private $defense;

	private $vitesse;

	private $force;

	

	

	public function statAgilité()

	{

		$agilité=$this->getDefense()*getVitesse();

		return $agilité;

	}

}

Pour ce qui est des ArrayObject, il sagit de collection d'objet, c'est parce que dans mon exemple j'ai une classe creature et une autre training et que mon Player à plusieurs creatures et trainings qui lui sont associé. On bdd quand tu as une relation One to Many tu utilises les clés étrangères, ici creature aurait en clé étrangère la clé primaire de Player. En OOP basé sur l'UML, ma classe Player va avoir une collection (tableau) où dedans seront stocké toutes les créatures qui lui sont associées (sous forme d'objet), une créature est un objet. Et dans creature il y a aura une propriété de type Player contenant l'instance de la class Player qui possède la créature.

bdd :
Player (#id, nom)
Creature (#id, nom, #id_player)

poo :

Class Player
- id de type entier
- nom de type chaine
- Collection d'objet chacun étant de type Creature

Class Creature
- id de type entier
- nom de type chaine
- propriétaire de type Player

(note : le php n'est pas un langage typé, donc on s'affranchit de notifier dans le code de quel typé est une variable ou un attribu)

Il faut savoir que l'utilisation de la POO avec une bdd est un cas particulier qui peut créer la confusion dans l'esprit.
Peut être serait il mieux de commencer par essayer de faire de la poo, puis une fois seulement lorsque tu seras confronté aux problèmes de persistance tu pourras rajouter la bdd. Comme tu veux. N'hésite pas pour les questions, je peux peut être aussi me motiver pour un vrai cas exemple.

[NicoMSEvent]

Nico, pourquoi le type de terrain dépendrait de l'utilisateur ?

si tank1->type de terrain(nord)!= eau alors tank1->bouge vers(nord)

Moi je dirais plutot

si carte.type_of_cell(tank1.posx, tank.posy) != eau alors etc...

:p

Tu as raison, en fait, je testais la future position du tank1 (au nord)

j'aurais du mettre :

si terrain->type(tank1->position(nord))!= eau alors tank1->bouge vers(nord)

[niahoo]

ah oui j'avais zappé que tu testais la future place