Discussion :

[tristan-f]

Bonjour, après avoir lu un max de tutos, vidéo et autres sur la POO en php, il faut que je passe a la pratique sinon je ne vais pas avancer :

Je dois réaliser (pour une commande bien réelle) un site dont le back-office permettra a un administrateur unique d'ajouter des titres de musique, et des infos relatives a ces titres tout ça sera stocké en bdd.

Je souhaite me servir de cette appli pour m'initier à la POO, alors je sais, le procédurale ferait très bien les choses pour une application aussi simple, mais je ne peux pas démarrer la POO immédiatement avec la construction d'une Usine a gaz.

J'attends donc d'aimables et bienveillants conseils sur mon idée :-)

Je pensais créer une class User dont les méthodes seraient :

Connexion
Ajout de titre
Modification de titre
Suppression de titre

(ces 4 méthodes seraient réservées à l'administrateur unique)

Dans une partie front-office, n'importe quel utilisateur pourrait voir ces titres de musique, les ranger, les trier selon différents critères (titre, artiste, genre etc), ces critères seront récupérés par simple formulaires, et la validation affichera la page avec les titres contenant le-dit critère.

Pour cette partie front-officle dois-je considérer chaque utilisateur public également comme des instance de la class User ?
si oui c'est également dans la class User que je mettrai d'autres méthodes pour les fonctions de tri ?

Ca n'est pas sur la syntaxe du language que j'ai besoin d'être éclairé mais sur le Model d'utilisation.

Je remercie grandement tous ceux qui sauront me faire progresser dans mon idée, car ça fait un moment que j'essaye de mettre un pied dans la POO.

bonne journée, et bon code.

Tristan F

[tdutrion]

Pour moi si tu veux voir l'intérêt de l'orienté objet dans ton appli tu as intérêt à la faire en MVC.

Du coup, tu peux imaginer des modèles (User, Album, Title, Artist...) et faire ta base de données en conséquence. Ensuite, il faudra faire des controlleurs, qui sont en gros des containers qui vont contenir la logique de l'application (par exemple créer un Album puis le sauver dans la base). Les vues correspondent pour leur part à l'affichage HTML.

Tu peux t'inspirer en partie du quick start de ZF ou ZF2 pour ton projet.

[tristan-f]

Ha merci, je ne pensais pas aller aussi loin en suivant un framework MVC.

Si je me limite à utiliser la POO sans encore parfaitement séparer la partie métier des controllers est ce que je peux créer une classe Musique et une classe User

et du coup ma class User aurait comme méthode :

Connexion
Ajouter musique
Modifier musique
Supprimer musique

et ma classe Musique aurait comme méthode :

afficher musique

???

en tout cas merci de m'avoir proposé une réponse plus large.

[Tsilefy]

Si tu penses juste te limiter à la seule classe User, tu vas te retrouver avec une God Class, une classe omnipotente, qui fera tout dans ton application. Dans ce cas, ce n'est plus de l'objet, ta classe est juste une réceptacle à fonctions.

Voici quelques pistes pour la réflexion:
Commence par réflechir à ton opération en termes d'entités et d'actions: quelles sont les caractéristiques d'un titre? Est-ce qu'il y a des groupes de titres? Des catégories? Que peux-t-on faire dans la partie admin? et dans la partie front-end?

Regarde quelles devraient être les responsabilités de chacun: est-ce que c'est l'utilisateur qui doit créer/modifier/supprimer les titres ou est que c'est le titre qui doit posséder les méthodes pour se créer/modifier/supprimer, ou est-ce que c'est une autre entité (une entité qui serait spécialisée dans la création/suppression d'objets).

Est-ce que tu as vraiment besoin d'une class User? et si oui, est-ce qu'il te faut deux classes User (SimpleUser et AdminUser par exemple)?

Une fois que tu auras défini tes différentes entités, leurs actions et leurs relations, c'est là que tu réflechis à la persistence (base de données).

Attention, pour un projet simple et qui n'est pas destiné à évoluer, tout ça peut sembler superflu (et ça l'est). Mais ton objectif est l'apprentissage...

Enfin, ne t'attends pas à trouver la bonne architecture du premier coup. Commence juste par quelque chose, et ensuite tu fais du refactoring.

[Tsilefy]

Le MVC n'est pas une fin en soi. Commence d'abord par apprendre la POO, et ensuite seulement tu te pencheras sur les patterns. POO !== MVC

[tristan-f]

Merci beaucoup Tsilefy pour cette réponse complète qui me fait poser les bonnes questions et retourner le problème dans différents sens.

Rassuré de voir qu'il n'existe pas de solution Unique et que le Refactoring n'est pas forcement cause de démarrage précipité…

[tdutrion]

En effet tu peux tenter de l'objet sans MVC. Dans ce cas, ce que je te conseillerais c'est de coller au début le plus possible à ce que tu faisais en impératif.

Par exemple, dans ta classe User tu veux mettre connexion. Je suis pas forcément sur que ce soit bien de mettre ça là mais c'est en effet une possibilité... Par contre je vois pas forcément comment tu veux architecturer le truc.

Parlons code pour être plus simple. Déjà, les noms des classes et variables : tu veux User et Musique... On se le fait en anglais ou en français ? Mélange pas les deux parce qu'à la longue ça compliquera le truc.

Imaginons une script de connexion :

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
 
<?php 
 
$user = isset($_SESSION['user'])?$_SESSION['user']:null; // TODO: retrieve User from session
 
if($user instanceof User and $user->isConnected()) {
   header('Location: admin.php');
   exit;
} elseif(
      isset($_REQUEST['login']) and !empty($_REQUEST['login']) and
      isset($_REQUEST['password']) and !empty($_REQUEST['password'])) {
          // user from db ($userInfo)
          // if user
              // $user = new User();
              // $user->setNickname($userInfo->nickname);
              // or: $user->setFromDb($userInfo);
              // set $_SESSION
         // else
             // redirect with errors in session
} else {
     // display form
}

Ce code est inutile mais montre un peu le fonctionnement que tu peux avoir au niveau de tes objets. L'idéal sera de laisser les objets traiter ce qui les concerne uniquement (les données). Tes objets sont des structures de données uniquement dans ton cas, et ils sont aussi responsable de gérer les modifications sur ces données en fonction des ordres donnés par les scripts responsables de la logique applicative.

Imagine par exemple ta classe User:

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
 
<?php 
class User {
    private $nickname;
    private $password;
    private $connected;
 
    public function getNickname() {
        return $this->nickname;
    }
 
    public function setNickname($nickname) {
        $this->nickname = $nickname;
        return $this;
    }
 
    ...
 
    public function setFromDb($dbObject) {
        $this->setNickname = $dbObject->nickname;
        ...
        return $this;
    }
}

Ensuite on améliore le code:

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
 
<?php
 
class User {
    ...
    public function authenticate($username,$password) {
        // code logic + db
        // $this->setFromDb($dbInfo);
        return $this; // ou null if row does not exist
    }
 
    public function save() {
        // save object info to db
        return $this;
    }
 
}

L'intérêt de MVC est surtout au niveau de la lisibilité du code et de la facilité à refactorer. De toutes façons c'est un concept qui s'imposera de lui-même si tu comprends un peu l'idée de l'objet.

Voilà en gros le concept en terme de code que j'utiliserais personnellement si je voulais faire comme toi, dis moi si tu veux d'autres infos ou si tu comprends pas quelque chose.