Discussion :

[beegees]

Bonjour à toutes et à tous,

Cela fait longtemps que j'aimerais développer un projet en PHP POO et un Ami m'a confié un petit projet qui me semble adapté à l'apprentissage de l'OO.

J'aurais en fait besoin d'une classe Utilisateurs.

Cette classe comprendrait donc des attributs assez communs (nom, prenom, email...) et certaines méthodes (ajout_Utilisateurs, maj_Utilisateurs,...)

Je me pose donc quelques questions :

1) Est-il mieux de développer une classe comme indiquée ci-dessus ou de créer un manager et une classe Utilisateur ?
2) Le constructeur devrait générer un accès à la bd ou un nouvel utilisateur ?
3) le fait de diviser mon code en deux classes (un manager qui s'occuperait de l’interaction avec la BD) et une autre classe pour l'hydratation de mes objets me permettrait d'avoir deux constructeurs (une pour chaque classe), le manager aurait dans son constructeur la création de la connexion à la BD et la classe Utilisateur s'occuperait d'appliquer à l'objet des valeurs correctes (niveau format).

Cela me gêne un peu d'avoir deux classes...

J'attends votre avis.

Merci d'avance.

bee

[comode]

Cela me gêne un peu d'avoir deux classes...

Il faut pas ^^

Dis toi que de toute façon, si tu veux vraiment faire de la POO, il te faudra au moins une class supplémentaire pour gérer la connexion à la BDD (que je te déconseille par ailleurs d'intégrer dans une class dont ce n'est pas le rôle, comme un manager). Le Design Pattern adapté pour ça, c'est le singleton, et il existe une class PHP standard pour la bdd (la fameuse PDO).

Après, libre à toi de faire un manager ou pas. Si tu en fait un, ça te fera 3 class avec la PDO, ce qui n'est pas un problème. Après, sur un petit projet, tu peux te passer du manager et tout gérer direct dans ta class utilisateurs. La question, c'est de savoir ce que t'apporterais un manager sinon un respect strict de certaines philosophie (elle même en amont de la philosophie orientée objet). Perso, je mettrais tout direct dans ma class utilisateur avec un constructeur qui prend en paramètre optionnel un identifiant d'utilisateur à charger depuis la BDD.

[Tsilefy]

Le principe de base est qu'une classe Utilisateur doit représenter l'utilisateur. La classe ne doit donc contenir que les propriétés et les méthodes qui sont propres à un utilisateur. Est-ce qu'un utilisateur a un nom? Oui. Est-ce qu'un utilisateur peut créer/supprimer d'autres utilisateurs? Dans ton cas, je pense que c'est non, à moins d'un cas spécifique (e.g. si Utilisateur contient d'autres Utilisateurs/objets qui héritent d'Utilisateur pour des raisons précis).

Regarde la cohérence interne de tes classes/objets, et la structure apparaîtra d'elle-même.

[comode]

Est-ce qu'un utilisateur a un nom? Oui. Est-ce qu'un utilisateur peut créer/supprimer d'autres utilisateurs?

A titre personnel, je ne pense pas que ça soit le mal absolu que d'utiliser des méthodes statiques pour ce genre de cas.
Genre une méthode static Create(nom, prenom, etc...) qui retourne une instance d'utilisateur, je trouve ça tout à fait acceptable.
De la même façon, au même titre qu'une méthode update(), une méthode non statique Delete() ne me semble pas déplacée (tant qu'elle prend pas un autre utilisateur à supprimer en paramètre hein).

Cela dit, si ces usages sont compatibles et cohérent en terme de POO pure, probablement que l'utilisation de certaines règles d'hygiènes (comme justement un manager) sont des choses à apprendre dès le début.

[beegees]

Salut,

Merci à vous deux pour vos réponses.

Je suis d'accord avec vous, autant apprendre directement les bonnes pratiques, comme j'aurais du apprendre directement la POO à l'école et pas la procédurale.

Dis toi que de toute façon, si tu veux vraiment faire de la POO, il te faudra au moins une class supplémentaire pour gérer la connexion à la BDD (que je te déconseille par ailleurs d'intégrer dans une class dont ce n'est pas le rôle, comme un manager). Le Design Pattern adapté pour ça, c'est le singleton, et il existe une class PHP standard pour la bdd (la fameuse PDO).

C'est vrai que la règle de base est "Une classe => un rôle", j'ai donc créé une classe qui me permet d'instancier une connexion à ma BD :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
 
<?php
 
class DatabaseConnection
{
 
    private static $_instance = null;
 
    private $_host;
 
    private $_user;
 
    private $_password;
 
    private $_dbname;
 
    private $_handle;
 
 
 
    private function __construct($dbname = 'nightkid')
    {
        $this->_host     = 'localhost';
 
        $this->_user     = 'root';
 
        $this->_password = 'root';
 
        $this->_dbname   = $dbname;
 
        $this->_handle   = null;
 
        try
        {
 
            $this->_handle = new PDO("mysql:host=$this->_host;dbname=$this->_dbname", $this->_user, $this->_password);
 
            $this->_handle->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
 
            echo 'Connection established and database "' . $this->_dbname . '" selected.';
 
        }
        catch (PDOException $e)
        {
 
            die('Connection failed or database cannot be selected : ' . $e->getMessage());
        }
 
    }
 
    //empêche l'objet d'être cloné
    private function __clone ()
    {
 
    }
 
    //singleton
    public static function getInstance()
    {
        if (is_null(self::$_instance))
        {
            self::$_instance = new self();
        }
 
        return self::$_instance;
    }
 
    public function handle()
 
    {
        return $this->_handle;
    }
 
}

J'ai récupéré ce code sur Internet et je l'ai adapté à mes besoins (j'ai par exemple ajouté la fonction clone).

J'ai pu lire ce commentaire à propos du code ci-dessus qui m'interpelle un peu :

Quelques remarques en vrac :
1) Tu n'utilises pas l'agument de ton constructeur.
2) Ton code serait plus simple si tu faisais hériter ta classe directement de la classe PDO (tu pourrais supprimer la variable $_handle).

Qu'en pensez-vous ?

Après, libre à toi de faire un manager ou pas. Si tu en fait un, ça te fera 3 class avec la PDO

Après réflexion et plusieurs recherches, je me suis aperçu qu'il est mieux d'avoir plusieurs classes que d'avoir une classe qui fait tout, d'où le "1 classe => 1 rôle"

Après, sur un petit projet, tu peux te passer du manager et tout gérer direct dans ta class utilisateurs. La question, c'est de savoir ce que t'apporterais un manager sinon un respect strict de certaines philosophie (elle même en amont de la philosophie orientée objet).

Justement, petit ou grand projet, je préfère directement respecter la philosophie orientée objet

[quote]

Le principe de base est qu'une classe Utilisateur doit représenter l'utilisateur. La classe ne doit donc contenir que les propriétés et les méthodes qui sont propres à un utilisateur. Est-ce qu'un utilisateur a un nom? Oui. Est-ce qu'un utilisateur peut créer/supprimer d'autres utilisateurs? Dans ton cas, je pense que c'est non, à moins d'un cas spécifique (e.g. si Utilisateur contient d'autres Utilisateurs/objets qui héritent d'Utilisateur pour des raisons précis).

Regarde la cohérence interne de tes classes/objets, et la structure apparaîtra d'elle-même.

Je suis d'accord avec ce que tu dis, merci.

Au plaisir d'avoir vos commentaires.

bee

[comode]

2) Ton code serait plus simple si tu faisais hériter ta classe directement de la classe PDO (tu pourrais supprimer la variable $_handle).

Qu'en pensez-vous ?

Qu'il a raison et qu'il faut faire dériver la class de la PDO, virer toutes les propriétés de la class (qui seront du coup prises en charge par PDO) et ne laisser que pour seul propriété $instance en static (et privé).

De la sorte, de n'importe où dans ton appli, une requete se fera :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DatabaseConnection::getInstance()->query('select * from utilisateur');