Discussion autour du concept de la POO

Smon · Le 05/01/2012, à 17:31

Faut juste savoir faire le tri entre ce qui doit être générique et ce qui ne doit pas l'être.

Ça s'appelle : "l'expérience".

Vous savez, "le truc de vieux con"

yohann · Le 05/01/2012, à 17:45

Évidemment le but est d'avoir quelques chose qui fonctionne à la sortie, la règle des 100 ligne n'est pas forcément à prendre au pied de la lettre mais quand on débute et qu'on a besoin de garde fou un peu précis c'est un bon indicateur qu'une classe devient trop complexe et nécessite d'être splittée.
pour reprendre ton exemple avec le visage et l’œil:
tu commence par faire un classe visage et de fils en aiguille ta classe dépasse les 100 lignes => une petite pause pour relire la classe => on constate que sur les 120 lignes de cette classe 50 sont consacrée à la gestion de la couleur de l'iris et la dilatation de la pupille => il est temps de créer une composition avec un objet œil.
c'est pas une règle absolue, juste un moyen de plus de contrôler qu'on est pas en train de faire trop nimp

Morgiver · Le 05/01/2012, à 20:40

C'est Torvald qui disait qu'une fonction devait faire une chose et la faire bien, je retrouve plus la citation

Mindiell · Le 05/01/2012, à 23:17

Une fonction (méthode pour un objet) n'est pas un objet, attention !
Rien que les getters et les setters ça peut parfois prendre un bon tas de lignes (et vu les commentaires à rajouter pour la doc...)

Mais je pense que tu as compris l'idée.
De plus, utiliser un framework peux vraiment t'aider à éviter de déborder

Morgiver · Le 06/01/2012, à 12:56

Bon, pour le petit test je me suis fait une class config qui permet de se connecter à la base de données avec des droits différents suivant le rang de l'utilisateur.

Je pense que ce test est une bonne démonstration du principe d'encapsulation au niveau de l'utilisation des attribut privé et public.
Ce n'est pas grand chose, mais j'aimerais pouvoir avoir un retour (avis, conseil, ce que vous auriez fait, critique, cassage de gueule, etc..).

<?php

class Config
{
    private $db;
    private $host;
    private $user;
    private $pass;
    private $bdd;
    
    public function __construct()
    {
        switch($_SESSION['rang'])
        {
            case "membre":
                $this->setDb('test');
                $this->setHost('localhost');
                $this->setUser('root');
                $this->setPass('');
            break;
            
            case "moderateur":
                $this->setDb('test');
                $this->setHost('localhost');
                $this->setUser('root');
                $this->setPass('');
            break;
            
            case "admin":
                $this->setDb('test');
                $this->setHost('localhost');
                $this->setUser('root');
                $this->setPass('');
            break;
            
            default:
                $this->setDb('test');
                $this->setHost('localhost');
                $this->setUser('root');
                $this->setPass('');
            break;
        }
        
        try
        {
            $pdo_options[PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION;
            $bdd = new PDO('mysql:host='.$this->host().';dbname='.$this->db().'', $this->user(), $this->pass(), $pdo_option);
            $this->setBdd($bdd);
        }
        catch (Exception $e)
        {
            die('Erreur : ' . $e->getMessage());
        }
    }
    
    //------------------------------\\
    //            Les GETTER            \\
    //------------------------------\\
    private function db()
    {
        return $this->db;
    }
    private function host()
    {
        return $this->host;
    }
    private function user()
    {
        return $this->user;
    }
    private function pass()
    {
        return $this->pass;
    }
    public function bdd()
    {
        return $this->bdd;
    }
    // Fin des GETTER
    //------------------------------\\
    
    //------------------------------\\
    //            Les SETTER            \\
    //------------------------------\\
    private function setDb($db)
    {
        $this->db = $db;
    }
    private function setHost($host)
    {
        $this->host = $host;
    }
    private function setUser($user)
    {
        $this->user = $user;
    }
    private function setPass($pass)
    {
        $this->pass = $pass;
    }
    public function setBdd($bdd)
    {
        $this->bdd = $bdd;
    }
    // Fin des SETTER
    //------------------------------\\
}

?>

Bon ok, ya 110 lignes Désolé pour les puriste

EDIT : Fait pas attention au compte root config de base de easyphp

Dernière modification par Morgiver (Le 06/01/2012, à 12:57)

yohann · Le 06/01/2012, à 13:10

Quelques feed-backs:

1) Le plus important à mon avis => ne pas utiliser de variable globale ou super globale à l'interieur de la Classe ça va justement à l'encontre du principe d'encapsulation que tu cites plus haut, c'est remplçable par un parametre du contructeur (__contruct($rang))
2) ta classe fait moins de 100 ligne si tu crée une fonction private set($db, $host, $user, $pass) ou set($connectionString) que tu appeles ensuite dans ton switch du contructeur
3) ton nouvelle objet crée un objet pdo dans le constucteur, qui n'est pas mis à jour lors du changement d'un attribut par les setter => tes setter ne servent à rien d'autre qu'a t'induire en erreur exemple:
myconf = new Config(admin); // un objet pdo est créé avec les parametres pour l'admin
myconf->setDb('nouvelleBase'); // l'adribut db est mis à jour mais le pdo reste configuré sur l'ancienne base
myconf->db(); // retourne nouvelleBase alors que config est encore connecté sur test

(c'était les points les plus importants à mon avis)

edit: et aussi un truc qui a pas gd chose à voir avec la POO => le default qui fait la meme chose que l'admin c'est moyen moyen...

Dernière modification par yohann (Le 06/01/2012, à 13:13)

Morgiver · Le 06/01/2012, à 13:18

1) Je devrais faire un nouvel attribut par exemple :

<?php
    private rang;
    private function rang()
    {
          return $this->rang;
    }
    private function setRang($rang)
    {
         $this->rang = $rang;
    }
    public function __construct($rang)
    {
          $this->setRang($rang);
          switch($this->rang())
          {
                 etc...
    }

2) Bonne idée de rassembler, vu que ce n'est pas des données fourni par l'utilisateur.

3) Pour ce point, je sais pas si j'ai bien compris. En faisant un $this->setDb('nouvelleBase'); cela devrait également enclenché une déconnexion de l'ancienne base et une reconnexion à la nouvelle base de données ?

Smon · Le 06/01/2012, à 13:47

mets tes infos de connexion dans un application.ini et charge le avec parse_ini_file(), s'plus classe.

Morgiver · Le 06/01/2012, à 14:13

Plus classe ? Ou alors ya un réel intérêt ?

Mindiell · Le 06/01/2012, à 15:02

Pour le moment, je dirais "seulement plus classe"

Pour le reste, l'idée est bonne et je plussoie les remarques de yohann. Cependant, j'aurais tendance à utiliser les variables directement et non les Setters/Getters au sein des fonctions privées. D'ailleurs, si tes variables ne sont pas censées êtres lues/modifiées via l'interface publique, ne mets pas de getter/setter (pour les variables internes, je ne vois pas l'intérêt, je viens de voir les setters/getters en private, ça crée une confusion).
Pour moi, c'est à toi de décider si la modification de Db enclenche une déco/reco, mais il faut le spécifier.
D'ailleurs, pourquoi ne peut-on pas modifier le host, ou le login ? C'est déjà moins générique. Si tu permets de modifier ça, en effet, comme dit yohann, je vois bien une fonction (privée) qui met à jour la ConnectionString complète à chaque modif, et une fonction (privée aussi) qui se déconnecte, puis reconnecte.

Morgiver · Le 06/01/2012, à 15:27

L'idée c'est d'utilisé plusieurs comptes Mysql avec des droits différents. Environ 4 comptes.
Visiteur, Membre, Moderateur et Admin. En configurant pour chacun l'accès qu'il peut avoir ou non sur chaque table de la base de données.

En fait j'hésite à faire ça ou alors un système directement implanter dans la gestion des requêtes, qui permet de voir à quelle table on essaye d'accéder et d'autoriser ou non l'accès.
Pour moi la solution Mysql est plus intéressante évidemment, mais je me demande ce que ça implique de créer chaque fois 4 utilisateurs.

Dernière modification par Morgiver (Le 06/01/2012, à 15:28)

yohann · Le 06/01/2012, à 15:46

@Morgiver:
1) pas besoin de stocker le rang (et donc d'en faire un attribut) si tu ne compte pas le changer fais en juste un paramètre du constructeur puis crées ton objet avec new Config('admin') par exemple.
2) je ne comprend pas vraiment ce que tu veux dire
3) En fait, je voulais juste dire que les getter/setters ne sont pas obligatoire, et que dans ton cas il vaut mieux ne pas en avoir du tout que d'avoir ceux que tu as mis, mais, comme cette classe est plus à but pédagogique qu'autre chose tu peux t'amuser a avoir des setters qui "servent à quelques chose" plutôt que des bêtes setters qui ne font que mettre a jour un attribut. D'une manière générale un setter qui ne fait que mettre à jour un attribut ne sert qu'a une seule chose : prévoir une évolution future de la classe sans changer l'API (c'est une forme d'encapsulation, tu utilise la classe comme avant depuis les autres objet, mais elle fait des chose en plus)

@smon
Dans l'absolu oui, les parametres de connection doivent plutôt être dans un fichier de conf, je considère que cet exemple est uniquement à titre pédagogique, pour une appli réel on a rarement besoin d'abstraire pdo qui est déja une abstraction de la bdd...

@mindiell
dans l'absolu, je dirai que cet objet n'a besoin ni des attributs, ni de getters ni de setters, juste un constructeur qui prend le rang en paramètre, ensuite d'un point de vue pédagogique, il est intéressant d'illustrer la visibilité des variables, ainsi, il n'y a par exemple aucune contre-indication à ne pas passer par les getters pour accéder aux attributs au sein de la classe

Dernière modification par yohann (Le 06/01/2012, à 15:49)

Luc Hermitte · Le 06/01/2012, à 15:52

L'OO c'est d'abord beaucoup d'abstraction au niveau de l'objet.
L'objet rend des services, on ne veut pas savoir comment il fait. Exemple que j'aime bien ressortir: http://www.siteduzero.com/forum-83-4119 … l#r3810730

Corolaire: getter et setters, c'est tout sauf de l'OO. C'est de l'orienté données: on abdique aux objets extérieurs un total contrôle sur notre état interne.

L'OO c'est aussi le polymorphisme dit d'inclusion. Là où un algo attend à manipuler un objet d'un certain type, on peut lui faire manipuler un objet enfant plus spécialisé (qui aura éventuellement adapté des points de variation prévus dans le parent/l'algo).
Mot clé: LSP (Principe de Substitution de Liskov)

La réutilisation, c'est un faux argument, et une fausse spécificité de l'OO. Bien au contraire, c'est régulièrement une mauvaise exploitation de certaines possibilités syntaxique des langages OO.

Dernière modification par Luc Hermitte (Le 06/01/2012, à 15:56)

yohann · Le 06/01/2012, à 15:58

On s'écarte de le POO, mais ton idée est intérressante, sauf que dans la plupart des appli web, les droit sur la bdd sont les meme pour tout le monde, les permission sont gérées en amont des connexions.
simplement parce que le grain des permission mysql ne permet pas de faire ce qu'on veut, par exemple pour le cas d'un forum avec la table posts:

admin => lecture/écriture
modo => idem
user => idem
visiteur => lecture
MAIS
un utilisateur ne doit pas pouvoir écrire ou modifier les posts d'un autre utilisateur que lui meme donc on est dans une impasse
idem pour les profils, il faut un accès en lecture/écriture sur la table profils et le droit de modifier uniquement son profil

Donc en général c'est l'appli qui a un utilisateur myql avec les droit de l'appli,

Smon · Le 06/01/2012, à 17:09

Morgiver a écrit :

Plus classe ? Ou alors ya un réel intérêt ?

Dans l'absolu, ton application devrait être totalement générique et tout ce qui est spécifique devrait être dans des fichiers de conf et/ou en base de donnée.
Ce qui fait que si tu as besoin de réutiliser ton application, tu la copies, tu modifies les fichiers de conf et ça tourne, pas besoin de toucher au code.

Mais bon c'est pas franchement utile pour un petit projet personnel.

Jules Petibidon · Le 06/01/2012, à 22:37

Smon a écrit :

Mais bon c'est pas franchement utile pour un petit projet personnel.

Non, mais c'est le genre d'objet intéressant à créer pour quelqu'un qui découvre le concept objet.
Un bon exemple de classe réutilisable dans différents projets. Et un bon exemple de simplification du code global qu'un objet utile peut apporter.

Morgiver · Le 23/01/2012, à 10:16

Salut, pour continuer la discussion j'aimerai aborder le sujet de l'influence que les objets peuvent avoir les uns sur les autres.
Je parlerai ici d'héritage.

J'ai un objet Application(), cet objet contient un attribut $erreur qui doit pouvoir contenir la liste des erreur détectée lors du déroulement de l'application.

Voici donc deux objet : Application et module qui hérite du premier.

<?php

class Application
{
    private $erreur = 'pouet';
    
    public function erreur()
    {
        return $this->erreur;
    }
    public function setErreur($erreur)
    {
        $this->erreur = $erreur;
    }
}

class Module extends Application
{
    private $app;
    public function __construct($app)
    {
        $this->app = $app;
    }
    public function makeError()
    {
        $this->app->setErreur('Une erreur s\'est produite');
    }
}

$app = new Application();
$mod = new Module($app);
$mod->makeError();
echo $app->erreur();

Rien de bien compliqué jusque là.

Ma question est de savoir si il n'y a pas moyen d'intervenir sans chaque fois devoir préciser l'objet ?
Si je tape ce code, il faudra à chaque ouverture que je transmette l'objet Application, c'est un peu chiant

Mathieu147 · Le 23/01/2012, à 10:23

Si ta classe Module hérite de ta classe Application, alors elle hérite aussi de ses attributs et méthodes. Tu peux donc utiliser directement setErreur() au sein de ta classe Module.

Morgiver · Le 23/01/2012, à 10:24

Ha oui merde chui con

EDIT : Bordel en plus j'ai fait plein de test, totalement inutiles xD

EDIT2 : Ca n'agit pas sur l'objet.

J'ai créer deux objet :

$app et $mod

$mod doit agir sur $app.

A mon avis il faudra que je spécifie toujours l'objet, sinon comment il pourrait s'y retrouver. Si j'ai deux objet app, comment les différencier ?

Dernière modification par Morgiver (Le 23/01/2012, à 10:27)

Smon · Le 23/01/2012, à 10:42

Pourquoi tu créés l'objet $app ?

Morgiver · Le 23/01/2012, à 11:44

L'exemple est un test pour voir comment je peux faire transité une erreur d'objet en objet.

Sur le site, je charge des modules, news, forum, etc... via mon objet 'Site' (ici application), j'ai une fonction qui recueil toutes les erreurs qui ont été trouvée et qui affiche le tout en bas de l'écran.

Avec évidemment les infos sur le module qui déconne, là ou ça a déconné dans le module, etc...

Donc l'idée, c'est de transmettre l'erreur de Module à l'attribut erreur de mon objet Application.
J'ai d'autre objet qui peuvent fournir des erreurs comme l'objet de bloc, l'objet d'observation de sécurité, l'objet du thème, l'objet des utilisateur, etc.., etc..

Smon · Le 23/01/2012, à 11:49

Oui donc c'est pas un héritage que tu veux mettre en place. Tu veux un objet partagé et du coup c'est un singleton qu'il te faut.

Dernière modification par Smon (Le 23/01/2012, à 11:56)

Morgiver · Le 23/01/2012, à 11:54

singleton ?

*s'en va taper une recherche sur gougueule*

Smon · Le 23/01/2012, à 11:57

Héhé ... Donner une miette est toujours plus efficace que de donner la tartine

Morgiver · Le 23/01/2012, à 12:04

<?php
    public static function getInstance () {
        if (!(self::$_instance instanceof self))
            self::$_instance = new self();
 
        return self::$_instance;
    }

Si je comprend bien le code, l'objet s’instancie lui même et retourne cette nouvelle instance de lui même.

Mais le code makeError() (dans l'objet module) agira directement sur l'instance de base ou alors sur le clone de cette instance ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 05/01/2012, à 17:31

Re : Discussion autour du concept de la POO

#27 Le 05/01/2012, à 17:45

Re : Discussion autour du concept de la POO

#28 Le 05/01/2012, à 20:40

Re : Discussion autour du concept de la POO

#29 Le 05/01/2012, à 23:17

Re : Discussion autour du concept de la POO

#30 Le 06/01/2012, à 12:56

Re : Discussion autour du concept de la POO

#31 Le 06/01/2012, à 13:10

Re : Discussion autour du concept de la POO

#32 Le 06/01/2012, à 13:18

Re : Discussion autour du concept de la POO

#33 Le 06/01/2012, à 13:47

Re : Discussion autour du concept de la POO

#34 Le 06/01/2012, à 14:13

Re : Discussion autour du concept de la POO

#35 Le 06/01/2012, à 15:02

Re : Discussion autour du concept de la POO

#36 Le 06/01/2012, à 15:27

Re : Discussion autour du concept de la POO

#37 Le 06/01/2012, à 15:46

Re : Discussion autour du concept de la POO

#38 Le 06/01/2012, à 15:52

Re : Discussion autour du concept de la POO

#39 Le 06/01/2012, à 15:58

Re : Discussion autour du concept de la POO

#40 Le 06/01/2012, à 17:09

Re : Discussion autour du concept de la POO

#41 Le 06/01/2012, à 22:37

Re : Discussion autour du concept de la POO

#42 Le 23/01/2012, à 10:16

Re : Discussion autour du concept de la POO

#43 Le 23/01/2012, à 10:23

Re : Discussion autour du concept de la POO

#44 Le 23/01/2012, à 10:24

Re : Discussion autour du concept de la POO

#45 Le 23/01/2012, à 10:42

Re : Discussion autour du concept de la POO

#46 Le 23/01/2012, à 11:44

Re : Discussion autour du concept de la POO

#47 Le 23/01/2012, à 11:49

Re : Discussion autour du concept de la POO

#48 Le 23/01/2012, à 11:54

Re : Discussion autour du concept de la POO

#49 Le 23/01/2012, à 11:57

Re : Discussion autour du concept de la POO

#50 Le 23/01/2012, à 12:04

Re : Discussion autour du concept de la POO

Pied de page des forums