P.o.o Constructeur / Constructeur Par Défaut

Dans la lignée de Sybler, je suis face à une question qui me bloque.

Je vais prendre un exemple: une classe joueur.

On ne peut avoir q'un seul constructeur par classe. Mais il y a deux facons de créér un objet joueur d'ou le problème, enfin ce n'est pas un problème mais plus un choix difficile.

Les 2 méthodes:

- passer en parametre les valeur du joueur et donc créer une occurence via ses valeurs.
- Ne passer qu'une valeur: l'ID. Et dans le constructeur avoir une requete de chargement qui créer une occurence grace au valeur de la table retournée par la requete.

Oui mais pb, c'est que j'ais besoin des deux" types" de constructeurs.

Avantage de la méthode 2:
SI je créer une occurence d'un joueur via la méthode n°2, cela est plus simple si jamais je dois ajouter un attribut a la classe joueur, je modifie simplement le constructeur et voila.

Problème: Si je veux ajouter un joueur. Je ne peux pas créer une occurence joueur qui n'existe pas encore, et donc je ne peux pas accéder au méthode du style "verifier le nom", "verifier le mail" etc.
Avec la methode 2 je pourrais plus que je passe en parametre les valeur et donc créer mon occurence.

c'est un peu compliqué j'espere avoir été clair. Donc mon soucis est quel choix de constructeur? Comment régler les pb du a l'un ou a l'autre?

PHP n'est pas un language très typé, tu peux donc faire un constructeur comme celui-ci:

Mais le polymorphisme est effectivement quelque chose qu'il serait agréable d'avoir en PHP sauf que tant que les variables ne seront pas plus typée, ca sera difficile pour PHP de faire quelque chose de réellement bien.

On peux pas faire du overloading juste en fonction du nombre des parametres
vue que php est pas typesafe ?

Comme ça :

?

(dsl pour le syntaxe)

/Ludvig

La surdéfinition/surchage de fonction n'est pas permise en PHP malheureusement. (Corrigez-moi si jamais je me trompe: ca ferais mon plus grand bonheur)

Et la syntaxe de constructeur que tu utilise est celle de PHP4. En php5 c'est vraiment __construct() ... et non le meme nom que la classe (juste pour faire différent des autres languages.. erf)

La surdéfinition n'existe toujours pas.

N'est-il pas possible de mettre des valeurs par défaut dans le cas d'une création de joueurs ? Ce serait des valeurs mises à zéro.

Comme on l'a dit, PHP ne fait que son entrée dans l'OO donc il faudra encore attendre pour pouvoir faire correctement de l'OO.

Ceci dit, après des recherches, la méthode __call peut-être utilisé dans ce sens ...

on peut la simuler en fonction du nombre d'arguments, via la fonction func_num_args :
http://fr.php.net/manual/fr/function.func-num-args.php

de mon coté j'utilise plutot des constructeurs du style:

hope it helps!

A+

Pascal

Et dire qu'une simple fonction ferait l'affaire. Pourquoi mais mon Dieu, pourquoi vous vous acharnez a faire de l'objet la ou il n'y en a nullement besoin.

Ca me tue moi ça lol.

Enfin cela dit, pour ton problème je penche plus pour un constructeur de type 1), suivit d'une fonction qui met a jour via la table.

On se rend compte pk quand on est dedans
Merci pour vos conseil.
Au final j'ais opter pour un constructeur du type:

_construct($id,$tab){

if($id!=0)
{
je charge a partie de la BD le joueur par son id
}
else
{
j'instancie un nouveau joueur grace au tableau)
}
}

... hum, je sais pas... peut-être parceque maintenant les actions prennent 80% moins de temps et de code.

Que tout est ordonné ( du genre: echo "Vous êtes actuellement dans le lieu: " . $perso->getLieu()->getNom(); )

Que j'ai une documentation généré automatiquement sur mon développement.

Que ca m'assure que mes programmeurs assistants utilise du code optimisé et qu'il ne modifie pas des données protégé.

ha oui ca me permet aussi de charger les informations sur demande seulement, mais de les garder stocker en mémoire et de ré-utiliser ces informations une seconde fois (ou plus) sans refaire de requête... et le tout géré de facon strictement transparente.


^^ Non pour vrai ca sert à rien la POO. C'est juste un truc pour rendre les Hello World plus compliqué.

Et si tout les languages sérieux (C++, C#, Java, etc) penchent pour ca, c'est juste pour être plus compliqué et se donner un air "cool" entre eux.

Et dire que tout ca EST FAISABLE AVEC DE SIMPLES FONCTIONS.

Je n'ai pas dit que ce mode de codage est sans intérêt, je dit juste que quand je fait un nom_joueur() bah moi aussi sa me retourne ce que je veux, que je peux le garder en mémoire, que c'est réutilisable sans toucher le coeur du codes et ainsi de suite.

Maintenant si vous êtes trop de mauvaise foi pour l'avouer sa ne regarde que vous.

Pour de petit projet oui totalement wells. Mais pas pour des projets plus imposant.

Je crois que le débat OOP vs Procédural n'a pas sa raison d'être dans le topic, ce n'est pas le thème et ça n'aidera en rien celui qui attend des réponses.

Pour ma part, si c'est possible je laisserais le contructeur vide ou avec un id optionnel. Si l'id est passé, tu passes par une méthode load( id ) pour charger le joueur et des getter/setter pour créer un joueur avec des données extérieurs. Ça évite de passer par une méthode avec beaucoup de paramètres ce qui rendrait le code moin clair.

Je sais que ca n'a pas beaucoup d'intérêt de faire ca, mais je ne peux pas m'en empecher:
+1


EDIT: (parceque juste +1 c'était trop gratuit )

Au fait, comment tu (wells) peux te permettre un tel jugement puisque tu n'a JAMAIS vu nos moteurs de jeu ? Es-tu dans le meme contexte de développement que nous ? (c'est à dire as tu une équipe de développeur ou tu est seul dans tes fonctions ? , à tu une documentation pour chacune de tes fonctions ? etc etc )

Ps.: Je viend d'aller voir TON moteur de jeu, et j'ai trouvé l'idée de demander aux joueurs de faire un résumé du background du jeu vraiment ... bonne ! hehe, good job ;p C'est pas breveté comme concept j'espère ... ? (Remarque moi ils se tappent un examen après l'inscription pour avoir accès à plus d'un seul secteur)

J'arrêterais la car effectivement ce n'est pas le sujet du post en question. Cependant pour coder depuis 7 ans en procédural en php, et faire de l'objet tout les jours en DotNet, je connais bien les deux options.

Je ne dit pas que l'objet n'a aucun intérêt. Je dit que parfois, dans certain cas de figure (comme la demande de ce post) une simple fonction fait souvent aussi bien sans avoir à ce prendre la tête sur des questions tel que posé ici.

Mais de reste je suis d'accord avec vous, l'objet a parfois un intérêt certain.

Mon moteur de jeu (environ 4 à 5 milles lignes) est 100% procédural, il tourne bien et j'attends qu'on me prouve, test à l'appuies, que le même moteur serait plus rapidement en objet.

Reste la question de la doc ,qui est il est vrai, est agréable de pouvoir générer automatiquement. Je travaille personnellement seul et je ne compte pas ouvrir mes sources donc le soucis est moindre, mais cela reste un +1 pour l'objet c'est certain.

"que le même moteur serait plus rapidement en objet."

.. non, mais par contre le projet aurrait peut-etre moins d'un million de ligne...



Sinon, je dérive le sujet (tout en gardant comme lien l'aspect "rapide" de la POO que wells à soulevé) vers une autre question Zan et moi sur MSN (enfait plus moi que lui je crois (Mais ca devrait intéresser tout le monde))



Est-ce qu'il vaux mieux garder un concept d'objet très théoriquement correct (aka ByTheBook) ou vaux t'il mieux sacrifier 2-3 principes parfois pour arriver à un résultat final plus optimisé dans certains cas précis.



Le cas de figure ici est:
- Une carte de banque donne accès à
- Un compte de banque qui lui fait partie
- D'une banque

Les relations:
- Une banque possède des comptes + Un compte est relié à une seule banque [ 1->N ]
- Les comptes possède des cartes + Une carte est relié à un seul compte [ 1->N ]





Voici une problèmatique (mais je ne veux pas une solution qui traite spécifiquement ce cas, le tout doit rester généralement ré-utilisable pour tous les autres cas impliquant Carte/Compte/Banque):

^^ oubliez pas que "Bob" à 10 cartes différentes, je n'ai donné qu'un exemple pour "imager un contexte".



Donc l'idée est d'arriver à gérer les données le plus optimalement possible.


Voici les quelques solutions présentée (Des mauvaises, mais parfois optimisés, aux techniquement superbes, mais souvent non-optimisés):

SOLUTION 1:

Avantage:
- Facilité d'instanciation: En chargeant une Carte, automatiquement les informations de Compte et Banque seront remplis correctement via l'appel des constructeurs parent.
- Possibilité d'effectuer une seule (1) requête SQL [ instancier dans une boucle while($arr=mysql_fetch_assoc()) et passer $arr aux constructeur ]

Inconvéniant:
- Le principe de l'héritage n'est pas applicable dans ce cas, puisqu'une carte n'est pas un compte et un compte pas une banque.
- Si 3 cartes proviennent de la même banque, la meme banque sera contenue 3 fois en mémoire.


SOLUTION 2:

Avantage:
- Facilité d'instanciation: En chargeant une Carte, automatiquement les informations de Compte et Banque seront remplis correctement via l'appel des constructeurs parent.
- Possibilité d'effectuer une seule (1) requête SQL [ instancier dans une boucle while($arr=mysql_fetch_assoc()) et passer $arr aux constructeur ]

Inconvéniant:
- Le principe de l'objet n'est pas respecté dans ce cas, puisqu'une carte n'est pas un compte et un compte pas une banque.. une carte ne devrais pas avoir les attributs de compte et de banque.
- Si 3 cartes proviennent de la même banque, la meme banque sera contenue 3 fois en mémoire.


SOLUTION 3:

Avantage:
- Les données sont optimisés en mémoire: Aucun doublon.
- Les données relatives au compte et à la banque sont uniquement chargé si elle sont utilisés.

Inconvéniant:
- Plus de requêtes SQL (mais vu que se sont des requêtes plus légère, ca pourrait être un avantage aussi)
- Créer des classes de Gestion (donc des classes de plus = structure moins simple et non uniforme à l'ensemble du projet)
- Complique l'utilisation générale du code (Il faut passer par une classe de gestion pour accéder à l'objet de classe Banque ou Compte)



SOLUTION 4:

Avantage:
- Respecte bien le concept de l'orienté objet

Inconvéniant:
- Instanciation TRÈS complexe: Je vois mal comment je vais arriver à créer tout ca de facon optimisée et correct considérant qu'au départ je n'ai qu'un seul ID de carte bancaire. (Il faut commencer la création par l'objet Banque normalement)


Vos commentaires / idées, etc...

Solution 4 of course, sinon ce n'est pas la peine de faire de l'objet. Oui c'est complexe, c'est pour cela que les frameworks de persistence existent (ezpdo entre autres). Ceux qui sont intelligents permettent de configurer une recuperation des objets lies a celui que l'on veut recuperer (je recupere tous les comptes lies a la banque), ou de ne les recuperer que s'ils sont utilises (lazy fetching)

Sauf que: qui possède réellement la carte ?

L'inventaire du personnage.

Alors lorsque je génère l'inventaire, comment est-ce que je vais arriver à lui intégrer une carte ?

Il faut avoir une solution qui permette, sans dupliquer l'information en mémoire de pouvoir à la fois:

- Afficher le nom de la banque d'une carte contenue dans l'inventaire d'un personnage.
- Afficher la liste des cartes d'une banque ou d'un compte.



EDIT:
La seule facon que je vois serait une méthode GestionBanque, qui contiendrait des méthodes telles que:

^^ Et je souligne qu'une classe gestionBanque serait à mon avis préférable car je ne vois pas ce qui pourrait "contenir" une banque (sauf un lieu, mais si je dois instancier un lieu (donc trouver QUEL lieu contiend à la banque) pour accéder à une carte contenue dans l'inventaire du personnage, au final je trouve ca ... peu agréable à utiliser comme système.

Heu ... j'ai bien compris les autres arguments, mais celui là je ne vois pas concrètement à quoi ça correspond coté poo.

Merci pour l'éclaircissement.

Bah c'est assez simple, regarde ce code (simplifié au maximum)

^^ mais mon point est que pour les BANQUES, pour pouvoir implanter un tel système, je ne vois pas d'autre choix que de créer une classe gestionBanque.
J'espèrais voir une personne me pointer une autre alternative, mais comme la plupart semblent rester silentieux...