[POO] PHP 5 : aggregate sans refkit [Tutoriel]

**Mr N.** · 14/12/2006, 19h36

oui oui ça c'est bon j'ai compris. En fait j'essaie de comprendre ton besoin. Ce "Main", c'est qui qui l'instancie et c'est qui qui va lui appeler les méthodes des plugins ?

**laurent_h** · 14/12/2006, 20h29

Oui oui ça c'est bon j'ai compris. En fait j'essaie de comprendre ton besoin.

Merci

Ce "Main", c'est qui qui l'instancie et c'est qui qui va lui appeler les méthodes des plugins ?

L'instanciation se fait par l'utilisateur et le chargement de plugin se fait par sa méthode LoadPlugin().

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
 
class Main()
{
    var $name = '';
 
    function loadPlugin(){}
 
    function execute(){}
 
    function setName($name){
           $this->name = $name;
    }
}
 
// dans le fichier Mail.class.php
class Mail()
{
     function MailWrite() {} 
     function MailSend() {}
}
 
 
$m = new Main();
$m->SetName('Coucou');
$m->Execute();
 
 
$m->LoadPlugin('Mail'); // charge le fichier Mail.class.php
$m->MailWrite();
$m->MailExecute();

**Mr N.** · 14/12/2006, 22h51

Qui va faire "new Main()" ?
Je sais je suis têtu mais si tu as du mal à répondre à cette question, c'est qu'il y a un truc louche dans ta conception non ?

**laurent_h** · 14/12/2006, 23h23

bah c'est l'utilisateur, l'idée c'est davoir un classe qui couvre les besoins principaux puis pour des besoins spécifiques il charge le plugin qui est une extension

N'hésite pas à me poser des questions si je m'exprime mal

Merci de ton aide

**laurent_h** · 14/12/2006, 23h32

c'est un peu comme le zend framework qui charge le plugin via la méthode statique loadClass()

Invité · 15/12/2006, 00h08

Envoyé par laurent_h

c'est un peu comme le zend framework qui charge le plugin via la méthode statique loadClass()

Zend::loadclass() n'est qu'un 'vulgaire' include, avec quelques vérifs et une gymnastique souple entre le nom de la classe<->nom du fichier de la classe.
Et un loadclass() permet d'utiliser la classe en instanciant ses objets à part.

Envoyé par laurent_h

l'idée c'est davoir un classe qui couvre les besoins principaux puis pour des besoins spécifiques il charge le plugin qui est une extension

Pourquoi vouloir à tout prix trainer ca sur la meme instance d'un objet, tout le temps ?

Ajouter/modifier des méthodes dynamiquement dans une classe, c'est incorrect d'un point de vue conception.
De plus je trouve cela plutot risqué, dans la mesure où l'on perd totallement le fil de qui fait quoi, qui peut faire quoi.

Et d'un point de vue débugguage, c'est la misère.
Quant aux fonctions Runkit, elles restent dans un statut expérimental.

Code :

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

1
2
3
4
5
6
7
8
9
 
$m = new main();
$m->SetName('Coucou');
$m->Execute();
 
 
$m->LoadPlugin('mail');
$m->MailWrite();
$m->MailExecute();

Pourquoi garder ici un seul objet $m et tout lui déléguer à la volée ?
Il est plus logique point de vue conception de faire

Code :

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

1
2
3
4
5
6
7
8
9
10
 
$m = new main();
$m->SetName('Coucou');
$m->Execute();
 
 
LoadPlugin('mail'); // équivalent à require ('mon_chemin/mail.class.php');
$n = new Mail();
$n->MailWrite();
$n->MailExecute();

**Mr N.** · 15/12/2006, 09h49

Envoyé par laurent_h

bah c'est l'utilisateur, l'idée c'est davoir un classe qui couvre les besoins principaux puis pour des besoins spécifiques il charge le plugin qui est une extension

Attends.... L'utilisateur il fait pas "new Machin()"... L'utilisateur il clique sur des boutons, il appelle des pages via son navigateur, rien d'autre....
Donc explique nous qu'est-ce qui se passe quand l'utilisateur appelle ton script index.php... Et si tu as un bout de code réel qui instantie Main et qui s'en sert on est preneur.

De toutes façons à partir du moment où on a une classe qui s'appelle "Main", j'estime qu'il y a un défaut de conception.

Envoyé par laurent_h

N'hésite pas à me poser des questions si je m'exprime mal

J'ai en effet du mal à te tirer les vers du nez...

**berceker united** · 15/12/2006, 10h00

Je suis daccord avec doctorrock sur le principe ça me parait un peut tordu voir risquer. Dans php il y a pas de notion main. Il y a pas de classe à tous faire. Dans ce genre de cas il faut pas hésiter à revoir ses prétentions à la baisses.

Pour répondre à Mr. N je crois que quand il parle de l'utilisateur, il parle d'un développeur qui souhaite ajouter un plug in via code pas un utilisateur via l'interface. Il souhaite faciliter l'ajout de plug in dans une application.

**Mr N.** · 15/12/2006, 10h24

D'accord, mais alors il faut qu'on parle des mêmes plugins...
Car pour moi un plugin est une fonctionnalité qu'on peut ajouter/supprimer d'une application sans douleur. C'est à dire que le coeur de l'appli ne devrait pas être modifié si on enlève un plugin.
Par exemple si j'enlève le plugin Mail, qu'est ce qui va se passer si à quelque part dans le code on appelait $main->MailExecute() ?
Je sais, c'est une interpretation totalement subjective, mais pour se comprendre il faut qu'on parle de la même chose. Sinon on en finit pas avec un dialogue de sourds. Or là, malgré mes éternelles question sur le pourquoi du comment, je n'ai toujours pas accès à la Vérité

Donc je dirais que pour répondre à la question initiale : faire de l'aggregation "automatique" est possible techniquement à condition de mouiller sa chemise, mais est signe d'une mauvaise conception de l'application.

**berceker united** · 15/12/2006, 11h15

Envoyé par Mr N.

D'accord, mais alors il faut qu'on parle des mêmes plugins...
Car pour moi un plugin est une fonctionnalité qu'on peut ajouter/supprimer d'une application sans douleur. C'est à dire que le coeur de l'appli ne devrait pas être modifié si on enlève un plugin.
Par exemple si j'enlève le plugin Mail, qu'est ce qui va se passer si à quelque part dans le code on appelait $main->MailExecute() ?
Je sais, c'est une interpretation totalement subjective, mais pour se comprendre il faut qu'on parle de la même chose. Sinon on en finit pas avec un dialogue de sourds. Or là, malgré mes éternelles question sur le pourquoi du comment, je n'ai toujours pas accès à la Vérité

Donc je dirais que pour répondre à la question initiale : faire de l'aggregation "automatique" est possible techniquement à condition de mouiller sa chemise, mais est signe d'une mauvaise conception de l'application.

Je suis daccord avec toi mais maintenant il savoir de quel point de vu se trouve. Sans douleur pour celui qui veut modifier l'application dans le code ou sans douleur pour celui qui est derriere l 'ecran qu'il ne voit rien de ce qu'il se passe derriere. Seul laurent_h peut répondre.

**laurent_h** · 15/12/2006, 14h55

Bon je crois que je vais faire extends en cascade

,
car croyais que ce serait plus simple en php 5

Le probleme est que Mr N a une vision de la poo pure, mon besoin est de faire un mixe entre la poo et du procedurale.

Mais bon, le moteur zend a changé en php 5.0

Merci pour toutes ces réponses

**Mr N.** · 15/12/2006, 14h59

Que ce soit en "poo pure" ou en mixte poo/procedurale ne change rien au problème

Invité · 15/12/2006, 15h39

L'enrichissement de classes, est une technique très rare, utilisée en particulier dans la programmation d'IA ( notion d'apprentissage ).

Dans ton cas, ca ne me semble pas adapté. Tu peux tout à fait designer une application sans enrichissement, d'autant que le module sous PHP(5) est experimental.
Je ne connais pas ton niveau en UML, mais je te conseille d'y faire un tour.
Avec les (bons) diagrammes UML, associés à une archi MVC, tu fais tout ca, et sans enrichissement dynamique...

**laurent_h** · 15/12/2006, 15h53

un exemple de moteur de template utilisant des plugins tiny but strong

http://www.tinybutstrong.com/plugins...lp#plugin_html

**Mr N.** · 15/12/2006, 16h37

Oui on est d'accord sur ce qu'est un plugin alors.
Les plugins de TBS fonctionne de la façon suivante :
Il doivent fournir une méthode OnInstall
et peuvent implémenter d'autres méthodes :

OnCommand, BeforeLoadTemplate, AfterLoadTemplate, BeforeShow, AfterShow, OnData, OnFormat, OnOperation, BeforeMergeBlock, OnMergeSection, AfterMergeBlock, OnSpecialVar, OnMergeField

Lors du chargement des plugins par TBS, ils sont stockés dans un tableau.
Puis par exemple avant de charger le Template, on va appeler la méthode BeforeLoadTemplate sur tous les plugins qui l'implémente.
(C'est le comportement que j'en déduit après avoir parcouru le code.)

Donc j'en déduit que le plugin HTML de TBS n'est pas intrusif. Il n'y a pas besoin de modifier le coeur de l'application pour ajouter le fonctionnement du plugin. A la rigueur un require et c'est tout... non ?

**laurent_h** · 17/12/2006, 18h17

Justement, je le faisais à la volée l'extension mais bon, j'ai résolu le problème en faisant des extends en cascade compatible PHP 4 et PHP 5

**berceker united** · 18/12/2006, 09h25

Envoyé par laurent_h

Justement, je le faisais à la volée l'extension mais bon, j'ai résolu le problème en faisant des extends en cascade compatible PHP 4 et PHP 5

Tu utilises des extends en cascade mais est-ce dans une raison logique UML ou pratique ?

**laurent_h** · 18/12/2006, 11h37

Pratique => compatibilité php 4 et php 5

**berceker united** · 18/12/2006, 11h39

Envoyé par laurent_h

Pratique => compatibilité php 4 et php 5

il est vrai que c'est facile de pluger en faisant des extends même si c'est pas du propre mais si ça marche ainsi personne ne viendra te faire le reproche. Ni vu ni connu j't'embrouille

**Mr N.** · 18/12/2006, 12h19

Ou comment faire de l'objet pour de l'objet et non pas pour répondre à un besoin de conception...

Il ne faut pas oublier que quand on écrit :

Code :

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

class Pomme extends Fruit

on est alors en mesure de remplacer extends par est un :

Code :

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

1
2
3
4
5
une pomme est un fruit
un employé est une personne
une voiture est un véhicule
...
...

Si on ne peut pas remplacer par est un alors il y a un probleme :

Code :

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

un main est un <plugin>

n'a aucun sens.
Par contre "un main utilise un <plugin>" oui.

Et encore une fois, le nom "Main" est à bannir.

[POO] PHP 5 : aggregate sans refkit [Tutoriel]

Langage PHP

Discussions similaires

Partager

Partager