Formulaire objet en php

Patator wrote:

Bonjour,

(snip - pas d'exemple à donner, mais je ne vois pas en quoi l'OO ne
serait pas adapté à des formulaires)

Tant que j'y suis, toujours sur lme web je trouve beacoup d'informations
concernant héritage et polymorphisme, mais rien concernant agregation ou
composition. Une bonne url serait la bienvenue.

<oop-basics>

class AvecComposition
{
$var truc;
$var bidule;

function AvecComposition() {
$this->truc = new ComposantTruc();
$this->bidule = new ComposantBidule();
}
}

class AvecAggregation
$var truc;
$var bidule;

// aggrégation 'statique'
function AvecAggregation(&$unTruc, &$unBidule) {
$this->truc = unTruc;
$this->bidule = unBidule;
}
}

class AvecAggregationDynamique extends AvecAggregation
{
// aggrégation modifiable dynamiquement
function setTruc(&$unTruc) {
$this->truc = unTruc;
}

function setBidule(&$unBidule) {
$this->bidule = unBidule;
}

}


La composition est une forme d'aggrégation, qui est une forme
d'association.

'association' signifie simplement qu'un objet (le client) utilise les
services d'un autre (le serveur).

'aggrégation' signifie que l'objet client garde une référence sur
l'objet fournissant le service, mais n'est pas responsable de sa
création (et donc ne devrait pas être responsable de sa destruction...).
Les cycles de vie des deux objets sont distinct

'composition' signifie que l'objet client est responsable de la création
(et donc de la destruction) de l'objet fournissant le service. Le cycle
de vie de l'objet serveur est dépendant du cycle de vie de l'objet client.

L'aggrégation et la composition permettent le polymorphisme, par ce
qu'on appelle 'héritage par délégation' :

class Server {
function doThis() {
...
}
}

class Client {
function Client(&$server) {
$this->server = $server;
}

// delegation
function doThis() {
$this->serveur->doThis();
}
}

Ce mode d'héritage offre plus de souplesse et de sécurité que l'héritage
d'implémentation ('extends').

Plus de sécurité, parce que les modifications dans l'imlémentation d'une
classe de base (ici en fait la classe Server) n'impacte pas les classes
dérivées (ici la classe Client).

Plus de souplesse car la classe 'de base' peut être choisie
dynamiquement à l'exécution :

function makeClient($baseClassName, $baseClassPath) {
require_once($baseClassPath);
$server = new $baseClassName();
$client = new Client($server);
return $client;
}

</oop-basics>


Voili voilà...

Bruno

Bonsoir,

(snip - pas d'exemple à donner, mais je ne vois pas en quoi l'OO ne
serait pas adapté à des formulaires)

<TROLL MODE=on>
Parce qu'il n'apporte absolument rien par exemple ?
</TROLL>

a++
JG

<TROLL MODE=on>
Parce qu'il n'apporte absolument rien par exemple ?
</TROLL>

arf!!
<ironie>
ben non, le C++ non plus, d'ailleurs :p cite moi un truc qu'on ne peux pas
faire en C .....?
</ironie>

ceci dit... Quelqu'un a commencé à zieuter php 5 et son côté plus objet??
c'est plus rapide qu'en 4, ou pas?

Lascap

John GALLET wrote:

Bonsoir,

(snip - pas d'exemple à donner, mais je ne vois pas en quoi l'OO ne
serait pas adapté à des formulaires)

<TROLL MODE=on>

<troll mode='on'>

Parce qu'il n'apporte absolument rien par exemple ?
</TROLL>

</troll>

Si tu veux troller !-)

Bruno

Bruno Desthuilliers wrote:

Le C ? C'est quoi ce langage de mangeur de quiche ? Les vrais, les durs,
programment en langage machine. D'ailleurs, cite moi un truc qu'on ne
peut pas faire en langage machine ?-)

http://unix.rulez.org/~calver/pictures/supercoder.jpg

--
Guillaume.

Ah, j'aime quand on suit mes trolls.

Mais c'est à moitié seulement un troll. Qu'est-ce que l'orienté objet va
bien pouvoir apporter à un ensemble de fonctions de gestion de formulaire ?
=> on va jamais dériver la classe donc il n'y aura pas d'héritage. Pour de
l'objet, c'est quand même un handicap sérieux.
=> reste seulement de pouvoir faire une boite noire avec des variables
internes d'état pour pouvoir par exemple fermer une balise automatiquement
si le développeur a oublié de le faire.
Le seul exemple auquel je pense est la balise </FORM> au bout du formulaire.
Non seulement il est logique de la lier au bouton SUBMIT, mais comme il n'y
a pas de destructeurs en php (pas plus en java sauf erreur de ma part) et
bien si le développeur oublie de faire l'appel à la fonction/méthode
"finFormulaire()" pas moyen de le faire pour lui.

Donc quand je dis froidement que l'OO ne sert à RIEN dans 99% des
cas où il est employé en PHP et que c'est normal parce que seule la
**notation ** objet est présente et pas les vrais principes de l'objet,
c'est pas juste
comme ça pour faire le mariole :-)

Maintenant si vous m'expliquez ce que faire un objet va bien m'apporter
par rapport à mettre les méthodes en tant que fonctions appelables n'importe
où dans le cadre d'un module de génération / traitement de formulaires, je
suis tout
ouïe.
a++
JG

John GALLET wrote:

Ah, j'aime quand on suit mes trolls.

Mais c'est à moitié seulement un troll.

Oui, effectivement. <troll>Un troll est généralement mieux pensé</troll>.

Qu'est-ce que l'orienté objet va
bien pouvoir apporter à un ensemble de fonctions de gestion de formulaire ?

Qu'est-ce qu'un langage de haut niveau va bien pouvoir apporté à un
projet ? Qu'est-ce que PHP va bien pouvoir apporter à un projet de site
web dynamique ? Qu'est-ce qu'un SGBDR doté d'un langage déclaratif va
bien pouvoir apporter à la gestion de données ? Qu'est-ce qu'un
ordinateur va bien pouvoir apporter au traitement de tâches répétitives ?

Je continue ?-)

=> on va jamais dériver la classe donc il n'y aura pas d'héritage. Pour de
l'objet, c'est quand même un handicap sérieux.

Lol. N'en dis pas plus, tu va t'enfoncer.

L'héritage d'implémentation n'est qu'une facilité de réutilisation de
code, pas la seule, et certainement la moins comprise des débutants
quant à son utilité réelle et à ses inconvénients. BTW, l'héritage
d'implémentation n'est en rien nécessaire pour faire de l'objet,
puisqu'on obtient un résultat similaire avec l'héritage d'interface + la
délégation.

Pour ma part, il est courant que je n'utilise pas une seule fois
l'héritage d'implémentation dans un projet OO.

Ceci étant, je ne vois pas ce qui te permet d'affirmer qu'il n'y aura
jamais de dérivation d'une classe 'Formulaire'. Ca dépend de l'appli.

Et enfin, *doit-il* y avoir une classe 'Formulaire' ? Qui permet
d'affirmer que c'est le *design* approprié ?

(question en l'air puisqu'il n'y a pas de specs sur lesquelles se baser,
mais question quand même).

=> reste seulement de pouvoir faire une boite noire avec des variables
internes d'état pour pouvoir par exemple fermer une balise automatiquement
si le développeur a oublié de le faire.

Ah bon ? C'est donc à ça que sert l'OO ? A fermer automatiquement des
balises ? Je m'étais souvent demandé, aussi. Merci pour cette
intéressante précision.

Le seul exemple auquel je pense est la balise </FORM> au bout du formulaire.
Non seulement il est logique de la lier au bouton SUBMIT, mais comme il n'y
a pas de destructeurs en php (pas plus en java sauf erreur de ma part)

Erreur de ta part !-) Il y a des destructeurs en Java.

<troll cible='java'>
Bon, on ne sait jamais avec certitude si et quand ils seront appelés, ce
qui les rends un peu moins utiles, mais bon, ils existent quand même.
</troll>

(tu vois, moi aussi je peux troller !-)

et
bien si le développeur oublie de faire l'appel à la fonction/méthode
"finFormulaire()" pas moyen de le faire pour lui.

Et s'il ne lit pas la doc, tant pis pour lui. Le but de l'objet n'est
pas d'empêcher les mauvais développeurs d'être mauvais - contrairement à
ce que semblent penser certaines personnes chez Sun.

Ceci étant, tu devrais peut-être te renseigner sur le pattern 'patron de
méthode', qui est très utilisé dans les framework pour éviter ce genre
de problèmes.

(Yes ! deux buzzwords dans une même phrase ! je marque des points, là !-)

Donc quand je dis froidement que l'OO ne sert à RIEN dans 99% des
cas où il est employé en PHP

Ce n'est peut-être pas l'avis des auteurs du code incriminé !-)

Ceci étant, j'admire ton travail : tu a réussi à lire 100 % du code PHP
objet existant, et à l'analyser suffisament en profondeur pour pouvoir
affirmer qu'il n'était pas nécessaire de l'écrire en OO - avec bien sûr
pour preuve une version non OO. Là, chapeau ! Juste une question : tu
dors quand ?-)

et que c'est normal parce que seule la
**notation ** objet est présente

Ha ? Pourtant, de l'avis de certains, PHP est loin d'être complet de ce
point de vue....

et pas les vrais principes de l'objet,

Qui sont ? (interrogation écrite, je relève les copies dans 10 minutes).

c'est pas juste
comme ça pour faire le mariole :-)

Non. C'est juste parce que, *si j'en juge à ce post* (désolé, je n'ai
pas d'autre élément), tu ne semble pas connaitre grand chose à la POO.

Ce que je ne te reproche pas, note bien, c'est juste ce ça donne
probablement un tout petit peu moins de crédibilité à tes propos sur la
question.

Maintenant si vous m'expliquez ce que faire un objet va bien m'apporter
par rapport à mettre les méthodes en tant que fonctions appelables n'importe
où dans le cadre d'un module de génération / traitement de formulaires, je
suis tout
ouïe.

Il est clair que l'on peut faire en procédural tout ce que l'on peut
faire en objet. On peut le faire en fonctionnel aussi. Il n'y a pas AMHA
de hiérarchie entre OO, procédural et fonctionnel.

Il y a par contre une hiérarchie entre code propre et code sale, et j'ai
personnellement plus de facilité à penser et écrire du code propre en
objet qu'en procédural - peut être parce qu'à part le C, j'ai surtout
utilisé des langages plus ou moins fortement orientés objet, et que ça
me vient naturellement.

Je suppose que si j'avais commencé la programmation par des langages
comme haskell ou OCaml etc..., j'aurais plus de facilité à penser et
programmer en fonctionnel - paradigme que j'ai (à mon grand regret) du
mal à intégrer, mais que je ne me permets pas de dénigrer au prétexte
qu'on peut arriver au même résultat en OO.

Donc, pour répondre à ta question, je ne sais pas ce l'OO peut
t'apporter à *toi*, je sais ce que ça m'apporte à moi, et ça me suffit.

Dis, quand tu aura un argument valide pour donner un peu de substance à
ton troll, tu me fera signe ?-) Parce que là, franchement, il n'y a pas
de quoi fouetter un gobelin.

Bruno

Re,

Oui, effectivement. <troll>Un troll est généralement mieux pensé</troll>.
Tout à fait :-)

Qu'est-ce que l'orienté objet va
bien pouvoir apporter à un ensemble de fonctions de gestion de formulaire
?

Je persiste. C'est marrant mais dès qu'on pose des questions précises sur
l'objet, les réponses se font sarcastiques, viles ou absentes.
Donc quel est l'avantage de la POO, en PHP, dans le cadre d'un module de
gestion de formulaires tel que décrit par l'auteur de l'article d'origine,
qui a même reposé cette question avec demande d'exemple à l'appui ? Marrant
mais à part une réponse complètement inutile pour un débutant ("fais donc un
framework") il a pas croulé sous les réponses montrant à quel point la POO
est utile dans le cadre de ce qu'il demande.

Je continue ?-)
Oui parce que là le trollomètre reste froid.

=> on va jamais dériver la classe donc il n'y aura pas d'héritage. Pour
de

l'objet, c'est quand même un handicap sérieux.
Lol. N'en dis pas plus, tu va t'enfoncer.

J'aime bien ça. Enfin ça dépend dans quoi.

BTW, l'héritage
d'implémentation n'est en rien nécessaire pour faire de l'objet,
puisqu'on obtient un résultat similaire avec l'héritage d'interface + la
délégation.
Interface ? Tu as vu des interfaces en PHP toi ? Les discours fumeux ne

marquent pas de points. Le java non plus.

Pour ma part, il est courant que je n'utilise pas une seule fois
l'héritage d'implémentation dans un projet OO.
Oui, donc c'est bien ce que je dis : c'est pas de l'orienté objet.

Ceci étant, je ne vois pas ce qui te permet d'affirmer qu'il n'y aura
jamais de dérivation d'une classe 'Formulaire'. Ca dépend de l'appli.
Tout à fait. Mais si tu arrives à me trouver un arbre d'héritage dans le

cadre de ce qui est demandé ici <3f4b2657$0$27032$626a54ce@news.free.fr> ça
m'intéresse beaucoup. Et de l'orienté objet sans un arbre d'héritage **moi**
je considère pas ça comme de l'objet, mais il paraitrait que je ne comprends
rien...

(question en l'air puisqu'il n'y a pas de specs sur lesquelles se baser,
mais question quand même).
Si, si, il y a des specs.

=> reste seulement de pouvoir faire une boite noire avec des variables
internes d'état pour pouvoir par exemple fermer une balise
automatiquement

si le développeur a oublié de le faire.
Ah bon ? C'est donc à ça que sert l'OO ?

Mais je ne sais pas moi à quoi ça sert, c'est justement le but de la

question^W^W^W du troll.

(tu vois, moi aussi je peux troller !-)
Rien que de prétendre que sans héritage on fait de l'objet, oui je m'en

étais aperçu.

Et s'il ne lit pas la doc,
La quoi ? Depuis quand on fait de la doc ?

(Yes ! deux buzzwords dans une même phrase ! je marque des points, là !-)
Ah oui, ça je te l'accorde, là mon trollomètre se réveille :-)

Ce n'est peut-être pas l'avis des auteurs du code incriminé !-)
M'en fous c'est le mien !

Juste une question : tu dors quand ?-)
Pas assez justement.

et pas les vrais principes de l'objet,
Qui sont ? (interrogation écrite, je relève les copies dans 10 minutes).

euh... Pouvoir faire le malin parce qu'on a écrit $toto->print(); au lieu de

print($toto). j'ai bon hein, j'ai bon ?

Non. C'est juste parce que, *si j'en juge à ce post* (désolé, je n'ai
pas d'autre élément), tu ne semble pas connaitre grand chose à la POO.
Ahhhh, on y vient, et c'est ça que j'adore et c'est pour ça que ce type de

thread restera toujours à l'état de Troll : dès qu'il s'agit de réellement
donner des exemples concrets de l'apport de la POO dans un cadre bien
précis, ses ardents défendeurs, tels des chevaliers en armure brillante, se
drapent dans leur dignité pour sortir l'Argument Suprême : "de toutes
façons, vous n'y comprenez rien".
Je te passerai mon pedigree et je te passerai les projets où j'ai vu un
intérêt à la POO. Mais clairement pour gérer 4 accès SGBDR et un écran en
PHP il n'y en a aucun.

Maintenant si vous m'expliquez ce que faire un objet va bien m'apporter
par rapport à mettre les méthodes en tant que fonctions appelables
n'importe

où dans le cadre d'un module de génération / traitement de formulaires,
je

suis tout ouïe.
Je réitère. Le cahier des charges est donné dans l'article "objets" de notre

cher Patator, j'attends des exemples concrets de classes et de méthodes avec
l'implémention des points intéressants qui montrent l'avantage de faire ceci
en POO par rapport à de la programmation non objet. Et à mon avis je peux
attendre longtemps. A part peut-être dans la classe de gestion des accès
SGBD.

Il est clair que l'on peut faire en procédural tout ce que l'on peut
faire en objet.
Oh que non. Vas essayer de gérer une file d'événements de clickodrome

(pardon : application graphique) en non objet. Vas essayer de faire
l'équivalent d'un push de données sur bus type corba en non objet. Non, on
ne peut pas tout faire en non objet.
Accessoirement, la réponse est à côté de la plaque. Tu noies le poisson (ou
l'Orc).

Il y a par contre une hiérarchie entre code propre et code sale, et j'ai
personnellement plus de facilité à penser et écrire du code propre en
objet qu'en procédural - peut être parce qu'à part le C, j'ai surtout
utilisé des langages plus ou moins fortement orientés objet, et que ça
me vient naturellement.
Nous sommes bien d'accord sur les préférences de codage de chacun. Le

meilleur langage, le meilleur éditeur, c'est celui qu'on connait. Mais c'est
toujours à côté de la plaque, comme argument. La question est je la répète :
qu'est-ce que l'objet va bien apporter à un module PHP de gestion de
formulaire en interaction avec un SGBD ?

mal à intégrer, mais que je ne me permets pas de dénigrer au prétexte
qu'on peut arriver au même résultat en OO.
Si tu sous entends que je dénigre la POO, tu te trompes fort. Je soutiens

seulement qu'il est beaucoup de cas où à part compliquer les choses simples,
elle n'apporte rien.

Donc, pour répondre à ta question, je ne sais pas ce l'OO peut
t'apporter à *toi*, je sais ce que ça m'apporte à moi, et ça me suffit.
A moi ? Le plaisir de troller de temps en temps. Ou de m'en servir quand

elle apporte quelque chose au **projet** et non pas à moi. D'ailleurs, si tu
cherches un peu dans les autres trolleries que je raconte depuis quelques
années, je soutiens toujours la même position : il n'y a pas de solutions
universelle, à chaque besoin la solution qui lui est la plus adaptée. J'ai
bien dit besoin. Pas incapacité du développeur à sortir de son conformisme
fossile dans lequel il est plus engoncé qu'un fémur de Mammouth dans la
forêt de Vercoyance. Donc quand faire de l'objet apporte un plus au projet,
j'en fais, quand ça ne fait que compliquer les choses j'en fait pas. Aussi
simple que ça.

Dis, quand tu aura un argument valide
Ah parce que c'est à moi d'en fournir ? Ah non, c'est pas du jeu. Moi je

prétends que ça n'apporte rien de faire des classes pour gérer des
formulaires. Libre à ceux qui ont compris ce qu'était la POO sans héritage
de me faire voir à quel point je me trompe afin que j'aille me fustiger à
l'aide d'orties fraîchement coupées (excellent pour les rhumatismes).
a++
JG

Maintenant si vous m'expliquez ce que faire un objet va bien m'apporter
par rapport à mettre les méthodes en tant que fonctions appelables n'importe
où dans le cadre d'un module de génération / traitement de formulaires, je
suis tout ouie

pas compliqué, il suffit de penser a toutes les choses que tu dois faire
quand tu gere un ofrmulaire. A partir de la, tu essaies de faire une conception
objet ou pas. Le diagramme des classes est visible ici :

http://php.classes.free.fr/FormFramework/FormObjectModel.png

dans ce framwork, il n'y a pas :

- le contexte ( différents parametres modifies par les formulaires)
- la gestion dynamique de la requete SQL en fonction de nombreux criteres
- le mode d'affichage.

Quand tout cela devient dynamique, un framework objet permet d'atteindre
assez rapidement l'objectif fixé, de facon modulaire.

Je pense qu'en programmation procedurale ca doit etre aussi faisable.
Attention a la lisibilité du code, aux variables globales ...

Le concept boite noir est un modele objet comme un autre. Il a l'avantage
de ne pas trop poluer l'espace de nommage. Il permet aussi la spécialisation
des methodes. Cela suppose d'avoir des methodes suffisament "atomique" pour
modifier de facon granulaire le fonctionnement d'une classe. (rarement le cas)

- Le cout de cette granularité : consomation de CPU.

avantage : modifier le comportement d'un objet sans avoir a bricoler le source
original. Mais cela nécessite pas mal de compétance. Et la portabilité n'est pas
garantie d'une version a l'autre de la bibliotheque.

PS : si vous connaissez SPIP, c'est l'exemple typique d'un plat de spagetti qui marche
super bien mais pas tres facile a faire evoluer, sans par les principaux developpeurs
d'origine.

// dans une bibliothèque lambda.
class MonoBloc {

Function Monobloc(){
$this->__constructor();
}

function __constructor(){
// blabla ....
}

function me_convient_pas(){
// blablablahhh
}

}

class NouvelleClasse extends MonoBloc {

Function NouvelleClasse(){
$this->__constructor();
}


// spécialisation ou correction de la methode.
function me_convient_pas(){
// pre-blablablahhh
$parent::me_convient_pas();
// blablablahhh
}
}