POO, gestion et utilisation

[niahoo]

Ok si c'était pas fini d'implémenter.
Fin bon, tu vois que l'array object n'est pas un simple array et ne remet pas en cause la protection des données. Bon j'arrête de flooder avec ça moi !

[christouphe]

LOL moi aussi. L'explication avec du code est toujours constructive

[Dexyne]

Ok je vois un peu le truc, par contre y'a pas mal de chose que je comprend pas leurs utilité mais je verrais par la suite.

Sinon ta mal fermer une cote après la fonction public function __toString() { ... }.

Par contre pourquoi met tu dans ton __construct ( *ici* ) {} tes variables ? Je ne vois pas à quoi ça sert vu qu'elles sont initialisés puis tu définis les $this->valeur = $var.

Après est-ce plus efficace (ou plus propre ou autre) de faire une fonction pour simplement afficher les données ?
'Fin ta pas fini mais prévoyais-tu de mettre des requêtes SQL pour récupérer les données enregistrées ? (je pense que oui mais bon).

Donc je vais voir pour mettre en place tout ça puis je vous post le tout (la je suis en cours on est sur PC mais faut quand même que je suive un minimum même si ce sont les bases de PHP qu'on voit ^^).

[Ter Rowan]

Je réagis au code de Christouphe (DAO_UNITE)

perso, j'ai voulu alléger le code pour pas me retrouver avec 50 lignes de '$this->_a = $a'
c'est probablement plus lent d'un point de vue exécution, mais tellement plus pratique

/**

 * instancie avec les valeurs un objet

 *

 * @param tableau est un tableau associatif propriété (sans "_") => valeur

 *              attention, seules les propriétés doivent indicer le tableau, toute autre clé générera une erreur

 * @since 1.0

 */ 

    public function __construct ($tableau)

    {

        foreach ($tableau as $champ => $valeur)

        {

            $champ ='_'.$champ;

            $this->$champ = $valeur;

        }

    }

j'utilise les mêmes notations que Christouphe, à savoir, pour chaque champ j'ai un _ devant son nom ($this->_a)

l'idée qui est derrière c'est que le tableau de données est le résultat direct d'une simple requête SELECT (résultat associatif nom du champ => valeur)

de fait, quand on modifie la table (en ajoutant un champ, en le renommant, etc...) il suffit d' ajouter/modifier une propriété dans la classe.

ainsi j'ai une classe "générique" qui ne fait pas grand chose à part ce morceau de code. Puis chaque classe spécialisée par table hérite de celle ci. Inutile alors de créer un constructeur pour chaque classe spécialisée.
Evidemment, dans le cas où les données en bdd ne conviennent pas directement on utilisera un constructeur spécifique du type :

    public function __construct ($tableau)

    {

        $tableau['le champ à retravailler'] = $tableau['le champ à retravailler'] + 48; // ou n'importe quelle opération



        parent::__construct($tableau);

    }

après on peut imaginer la même chose pour les méthodes getter et setter via l'appel des méthodes magiques (si tous les champs sont accessibles de la même manière)

ça évite d'avoir trop de code sans intérêt, on peut pas dire que :

[code=PHP]function getToto()
{
return $this->_toto;
}

soit très intéressant à lire ^^

maintenant j'utilise quand même très peu les getters et les setters, mais c'est uniquement car le côté générique n'est valable que pour 3-4 données, tout le reste étant en spécifique voire interdit d'accès (protected)

---

qu'est ce que j'ai glandé pour que mon code php ne s'affiche pas ?
à oui, mieux comme ça ^^

[christouphe]

[Dexyne]

J'ai pas tout compris à l'utilité de ça mais en gros toutes les variables sont foutu dans un tableau ?
Comment les met tu dans le tableau ? (tu parles de SQL alors ça m'embrouille un poil )

Et les balises code se ferme avec [_/code] le bouton remet un code=" " 'fin bon.

Sinon christouphe en faite tu fais un côté qui gère l'affichage tout ça et un autre la gestion des données ?

[christouphe]

oui, j'ai séparré la partie affichage de ma partie traitement, sauf pur les objets "affichables" qui on leur propre code d'affichage.

[Ter Rowan]

J'ai pas tout compris à l'utilité de ça mais en gros toutes les variables sont foutu dans un tableau ?
Comment les met tu dans le tableau ? (tu parles de SQL alors ça m'embrouille un poil )

regarde le dernier code de christouphe (factory)

le résultat de la requête SQL est stocké dans $data qui est une matrice

$data[0] = premier enregistrement lu
$data[1] = deuxième enregistrement lu
$data[2] = troisième enregistrement lu
$data[3] = quatrième enregistrement lu


d'où la boucle qu'il fait pour créer les objets :

foreach ($data AS $unite)

dans $unite tu as un enregistrement de la base de données. Fonction des options que l'on met dans pdo pour lancer la requête, le tableau $unite peut avoir comme index le nom du champ tel que lu dans la bdd

c'est justement ce qu'utilise Christouphe :

$oUnite = new daoUnite($unite['id'],
$unite['nom'],
$unite['description'],

maintenant perso, je ne me soucie plus de cela, là où Christouphe, retape chaque champ dans le code factory et dans le code de la classe unité, moi je réduis fortement les lignes car je m'appuie directement sur le tableau de la requête SQL

$oUnite = new daoUnite($unite);

dans tous les cas le système est le même


1) la factory qui lance la requete SQL
2) la factory qui récupère n enregistrements sous forme de tableau associatif (avec les noms des champs bdd)
3) la factory qui boucle sur les enregistrements et crée autant d'instances de la classe qu'il y a d'enregistrements
4) le constructeur de la classe qui reçoit comme paramètres (moi tableau, christouphe en clair) les données de l'enregistrement et les stocke dans son instance

---

a noter, y a quand même un intérêt que je vois à écrire en clair plutôt qu'à utiliser ma méthode "générique", c'est que la méthode de christouphe permet une plus grande liberté de nommage entre les champs bdd et les propriétés de l'objet, mais je n'en ai pas l'utilité personnellement

[christouphe]

Bon moi il me les faut, car pour exemple, il m'a fallu renommer un attribut qui croisait avec un autre ajouté en BDD. Mais bon une fois fait...Ce n'est plus à faire (C/C quand tu nous tiens).

C'est vrai que les deux approches sont similaires et cela dépend aussi comment tu comptes développer.

[Dexyne]

Ok ok, je voulais savoir les variables qui sont dans __construct ( *ici* ) {} et celle en private ont-elles un lien ?
Si non à quoi servent-elles alors ?

Aussi pourriez-vous m'expliquer (théoriquement pas par le code) comment fonctionne les patterns en gros, si y'a des schéma c'est mieux, j'ai regarder vite fais mais je comprend pas vraiment le fonctionnement. Faut-il inclure le pattern ? Si oui où ? (dans la class ?)

J'aimerais aussi savoir comment vous organisez vos fichiers parce que perso je sais jamais comment bien les organiser xD.
Je précise que pour le moment je n'utilise pas de MVC (je verrais si ça marche pour retranscrire ^^).

Sinon merci à nouveau des infos et de l'aide .