j'apprends php (3)

Olivier Masson a écrit :

Le 31/03/2010 13:28, Pascal a écrit :

Pas d'héritage multiple avec PHP

Ok, donc ça existe. Le contraire me semblait étrange.

Ca existe, certes, mais en pratique ça pose au moins autant de problèmes
que ça n'en résoud. Particulièrement dans un langage à typage dynamique,
où on n'a pas besoin de l'héritage de type pour supporter le polymorphisme.

Après, me débrouiller avec ce que j'ai, c'est simple. Mais j'aurais
voulu faire plus conventionnel pour apprendre. PHP5 ne le permettant
pas, on va faire du copier/coller.

Mauvaise idée AMHA. Cette solution aussi créée au moins autant de
problèmes qu'elle n'en "résoud".

Le 02/04/2010 01:09, Bruno Desthuilliers a écrit :

Olivier Masson a écrit :

Le 31/03/2010 13:28, Bruno Desthuilliers a écrit :

Problème de conception assez courant hélas consistant à abuser de
l'héritage au lieu de réfléchir. Après, sans connaître le contexte, pas
moyen de dire quelle serait la bonne solution, mais à vue de nez on
pourrait penser aux patterns "décorateur" et "stratégie".

Bien entendu, j'ignore ce que sont ces patterns.

C'est relativement documenté sur le net.

Le pattern stratégie consiste à déléguer une partie déterminée du
comportement à un autre objet (ou à une fonction de rappel pour ce que
ça vaut), généralement spécifié(e) à l'instanciation. Ca permet de
"plugger" des comportements différents sans devoir toucher à la classe
de base ou créer une nouvelle sous-classe.

Le pattern décorateur consiste à ajouter/adapter les fonctionnalités
d'un objet en le décorant dans un autre objet (compatible du point de
vue de l'API of course), le quel délèguera une partie du travail à
l'objet d'origine.

Très intéressant, même si j'ai dû couper la musique pour me concentrer :)
Mais j'ai une question plus générale à te poser : tu sembles (j'ai
appris à prendre du recul et à tout relativiser) avoir de solides
connaissances en développement.

Par contre, le moindre micro-projet parait être une montagne de
complexité avec ton savoir-faire (car il faut, entre autres, tout
concevoir à la (ta ?) perfection et avec une vision sur le long terme).
Certes, peut-être pas pour toi qui a l'habitude, mais pour le
commun-des-mortels-qui-développent-déjà-un-tout-petitpetit-peu que je
suis, c'est plutôt abscons et très théorique.

Ce qui m'a séduit il y a peu, parce que j'essaie de l'appliquer depuis
fort longtemps, c'est le concept de méthode agile - oui, cela devient
très "tendance" et donc probablement surestimé -.

Or, j'ai *l'impression* que tu en es à l'opposée. Est-ce que je me
trompe ? Penses-tu que tes méthodes soient adaptées à un projet de
taille minuscule, modeste, moyenne ?
L'argument "tu ne sais pas ce que ton projet sera demain", je le
comprends, mais il est parfois beaucoup plus productif (et rentable,
efficace...) de faire un projet à sa juste mesure puis, si besoin est,
repartir en partie ou en totalité à zéro, avec une méthode adaptée à la
nouvelle importance du projet.

Ça me fait un peu penser à MVC que j'avais, il y a encore peu de temps,
honte de ne pas utiliser.
Finalement, maintenant que je fais parfois mon propre MVC, je suis tout
à fait convaincu que cette structure n'a rien d'idéale (et il m'arrive
donc de l'utiliser uniquement sur des parties de site).

Qu'en penses-tu ?
Tout ceci est important pour moi car on ne lit que rarement sur le net
des propos nuancés, qui prennent en compte des contextes très différents
(le meilleur CMS c'est X, le meilleur framework JS c'est Y, etc.)

Olivier Masson a écrit :

Le 02/04/2010 01:09, Bruno Desthuilliers a écrit :

Olivier Masson a écrit :

Le 31/03/2010 13:28, Bruno Desthuilliers a écrit :

Problème de conception assez courant hélas consistant à abuser de
l'héritage au lieu de réfléchir. Après, sans connaître le contexte, pas
moyen de dire quelle serait la bonne solution, mais à vue de nez on
pourrait penser aux patterns "décorateur" et "stratégie".

Bien entendu, j'ignore ce que sont ces patterns.

C'est relativement documenté sur le net.

Le pattern stratégie consiste à déléguer une partie déterminée du
comportement à un autre objet (ou à une fonction de rappel pour ce que
ça vaut), généralement spécifié(e) à l'instanciation. Ca permet de
"plugger" des comportements différents sans devoir toucher à la classe
de base ou créer une nouvelle sous-classe.

Le pattern décorateur consiste à ajouter/adapter les fonctionnalités
d'un objet en le décorant dans un autre objet (compatible du point de
vue de l'API of course), le quel délèguera une partie du travail à
l'objet d'origine.

Très intéressant, même si j'ai dû couper la musique pour me concentrer :)

Mais j'ai une question plus générale à te poser : tu sembles (j'ai
appris à prendre du recul et à tout relativiser) avoir de solides
connaissances en développement.

Tu a bien raison de relativiser.

Par contre, le moindre micro-projet parait être une montagne de
complexité avec ton savoir-faire (car il faut, entre autres, tout
concevoir à la (ta ?) perfection et avec une vision sur le long terme).

Non. Contrairement à ce que tu sembles croire, je suis pour les
solutions simples (disons "aussi simples que possibles"), et ça fait
bien longtemps que j'ai cessé de croire qu'on pouvait "tout concevoir à
la perfection". Quand à la "vision sur le long terme", la mienne se
restreint généralement à essayer de finir le projet avec pas trop de
retard et pas trop de conneries dedans.

Par contre:

Certes, peut-être pas pour toi qui a l'habitude,

Effectivement, l'expérience aide à éviter dès le départ certaines
vieilles erreurs. Ca n'empêche pas d'en faire de nouvelles, hélas :-/

mais pour le
commun-des-mortels-qui-développent-déjà-un-tout-petitpetit-peu que je
suis, c'est plutôt abscons et très théorique.

Crois moi, quand tu a été confronté plusieurs fois au même problème, ça
n'a plus rien de théorique.

Ce qui m'a séduit il y a peu, parce que j'essaie de l'appliquer depuis
fort longtemps, c'est le concept de méthode agile - oui, cela devient
très "tendance" et donc probablement surestimé -.

Possiblement, mais il y a quelques considérations pleines de bon sens là
dedans, spécialement pour des petits projets avec des petites équipes,
des deadlines serrées, et des spécifications "flottantes" - donc une
bonne partie du développement web.

Par contre, et on le soulignera jamais assez, ces méthodologies ne
peuvent fonctionner correctement que pour des équipes composées
majoritairement de personnes expérimentées.

Or, j'ai *l'impression* que tu en es à l'opposée. Est-ce que je me
trompe ?

Oui.

Le fait d'utiliser par exemple un pattern décorateur (pas forcément de
façon "canonique" d'ailleurs - ce sont des motifs de *conception*, pas
d'implémentation) plutôt que l'héritage dans un cas comme celui que tu
soulèves ne relèves pas du BigDesignUpFront - c'est le genre de choix
qui s'impose d'eux-mêmes pendant le développement quand on connait le
problème et la solution. C'est à peu près aussi naturel que de
factoriser le code commun dans une fonction (ou méthode) quand on voit
qu'on est en train de se répéter et que cette répétition n'est pas
accidentelle.

Penses-tu que tes méthodes soient adaptées à un projet de
taille minuscule, modeste, moyenne ?

La plupart des projets sur lesquels je bosse sont de taille suffisament
modeste pour qu'un seul dév y soit affecté. Sur les plus gros, on est
deux dév... Quant à mes méthodes, au final, ça se résume à ça:

http://www.cafenware.com/la-rache/index.php?z=2

L'argument "tu ne sais pas ce que ton projet sera demain", je le
comprends,

En ce qui me concerne, c'est un excellent argument pour ne PAS partir
dans des trucs inutiles. Par contre, ça n'implique pas de laisser son
cerveau au vestiaire. Ce n'est pas parce que je ne sais pas comment le
projet va évoluer que je ne vais pas essayer d'avoir ajourd'hui une
solution raisonnablement propre.

mais il est parfois beaucoup plus productif (et rentable,
efficace...) de faire un projet à sa juste mesure puis, si besoin est,
repartir en partie ou en totalité à zéro, avec une méthode adaptée à la
nouvelle importance du projet.

Oui et non. Je n'essaie pas de faire plus que ce qu'il y a dans les
specs, justement parce que je n'ai aucune idée de comment le projet va
être amené à évoluer (et qu'à chaque fois que j'ai essayer de deviner,
je me suis planté). Par contre, par expérience, garder son code
raisonnablement propre et factorisé, avoir un schéma de données
normalisé et correspondant au problème à résoudre, etc etc, ça rend
service quand les premières demandes d'évolutions arrivent.

Ça me fait un peu penser à MVC que j'avais, il y a encore peu de temps,
honte de ne pas utiliser.
Finalement, maintenant que je fais parfois mon propre MVC, je suis tout
à fait convaincu que cette structure n'a rien d'idéale (et il m'arrive
donc de l'utiliser uniquement sur des parties de site).

Je vais (encore...) faire figure de puriste pédant, mais parler de MVC
pour du dev web est assez inapproprié - l'architecture MVC (la vraie)
concerne les GUI traditionnels, et réponds à des besoins (et à un modèle
d'exécution) très différents.

Maintenant, l'approche consistant à séparer autant que possible les
trois composants que sont #1 la logique applicative, #2 la gestion des
actions de l'utilisateur et #3 la logique de présentation, est
globalement une approche plutôt saine quelque soit le contexte.

Note cependant que rien de tout ça ne requiert de faire de la POO ni de
partir dans des délires d'"architecte astronaute". On peut appliquer
cette approche *très* simplement en bon vieux PHP procédural à la papa.
On n'a pas attendu la POO pour faire du code modulaire, tu sais ?

Qu'en penses-tu ?

De quoi ?-)

Tout ceci est important pour moi car on ne lit que rarement sur le net
des propos nuancés,

Au risque de te décevoir, je ne suis pas spécialement connu pour mon
sens de la nuance, loin s'en faut !-)

Le 02/04/2010 17:59, Bruno Desthuilliers a écrit :

Possiblement, mais il y a quelques considérations pleines de bon sens là
dedans, spécialement pour des petits projets avec des petites équipes,
des deadlines serrées, et des spécifications "flottantes" - donc une
bonne partie du développement web.

Par contre, et on le soulignera jamais assez, ces méthodologies ne
peuvent fonctionner correctement que pour des équipes composées
majoritairement de personnes expérimentées.

Pas vraiment d'accord.
Forcément, des personnes expérimentées feront du meilleur travail.
Forcément, quand le simple bon sens est décrit dans une méthode, qu'il
faut appliquer cette méthode, qu'elle repose sur des critères précis (et
à trop en faire s'éloigne de la simplicité qu'elle prone), il faut des
gens compétents.
Mais, contrairement à ce que tu dis, je pense que les méthodes agiles -
encore une fois, sans rentrer dans des descriptifs complexes mais en
gardant juste les bons principes - permettent à des équipes peu
expérimentées de s'en sortir bcp mieux.
Certes je ne fais pas d'XP mais, naturellement, j'essayais d'appliquer
beaucoup de points décrit dans l'XP, avant même que j'en aie (eusse ?)
entendu parler.

La plupart des projets sur lesquels je bosse sont de taille suffisament
modeste pour qu'un seul dév y soit affecté. Sur les plus gros, on est
deux dév... Quant à mes méthodes, au final, ça se résume à ça:

http://www.cafenware.com/la-rache/index.php?z=2

C'est amusant, mais à moins que tu ne sois purement autodidacte et que
tu n'aies jamais lu de bouquins sur le développement, tu as forcément
été influencé par des livres, des revues, des sites, des profs, etc.

Maintenant, l'approche consistant à séparer autant que possible les
trois composants que sont #1 la logique applicative, #2 la gestion des
actions de l'utilisateur et #3 la logique de présentation, est
globalement une approche plutôt saine quelque soit le contexte.

Oui, lorsque l'on parle de journées de dev pour un site.
Sur un site qui utilise une poignée de ligne de code, c'est un peu
ridicule (et lent, et peu pratique, et à l'inverse du but de ce type
d'architecture).

Note cependant que rien de tout ça ne requiert de faire de la POO ni de
partir dans des délires d'"architecte astronaute". On peut appliquer
cette approche *très* simplement en bon vieux PHP procédural à la papa.
On n'a pas attendu la POO pour faire du code modulaire, tu sais ?

Oui, ça, c'est bien la chose que je sais puisque je l'applique :)

Au risque de te décevoir, je ne suis pas spécialement connu pour mon
sens de la nuance, loin s'en faut !-)

La nuance n'est pas vraiment une qualité partagée par beaucoup, surtout
sur le net ! Mais je le disais : j'ai appris à relativiser ;)