Discussion :

[MonsieurPoulet]

Salut à tous,

Nouvellement inscrit sur le forum, ceci est mon premier topic. J'ai régulièrement trouvé des réponses à mes questions sur developpez.com sans jamais participer, j'y remédie aujourd'hui !

Cela fait maintenant plusieurs années que je développe en PHP et je souhaiterais passer à la vitesse supérieure. En effet actuellement, je développe principalement des sites de petite taille, en PHP procédural de niveau correct, parfois saupoudré d'objets mais sans plus.

A la base programmeur AS3 (Flash), j'ai une bonne connaissance de la POO mais j'ai des difficultés à répliquer ces schémas sur le PHP. Par exemple : en AS3, si je veux faire un player vidéo, je vais avoir une classe Control que je vais étendre pour faire BoutonPlay, BoutonStop, etc. boutons que je vais instancier au sein de BarreDeMenu, que je vais instancier au sein de PlayerVideo aux cotés de ma Video. La logique objet y est simple vu que les objets ne sont pas des abstractions (qu'un bouton soit un objet, ça parait logique...). C'est précisemment ce schéma que j'ai du mal à adapter au PHP, que j'utilise pourtant quotidiennement.

Je lis actuellement PHP Design Patterns de William Sanders et je bloque sur la première (ouch) : Factory Method. Je comprends le principe et la mise en oeuvre mais difficilement l'utilité. Et en cherchant des exemples sur le web, entre mon cours sur la POO qui manque de rigueur et ceux d'ici qui sont trop pléthoriques pour que je sache par lequel commencer, je suis un peu paumé.

Voila pour l'intro.

En résumé : je veux arrêter le procédural en PHP et j'ai choisi pour y parvenir les étapes suivantes :

• Revue des différentes design patterns via le bouquin cité plus haut
• Apprentissage d'un moteur de template (Rain.TPL a priori) pour pouvoir facilement mettre en oeuvre la design pattern la plus commune en PHP : le MVC.
• Apprentissage d'un framework PHP : j'ai eu de bons retours sur Laravel

Est-ce que vous verriez des étapes préliminaires ou des compléments d'information de qualité choisie, notamment sur les design patterns et la MVC ?

Merci !

[Tsilefy]

Les design patterns sont des solutions pour résoudre un problème. Si tu n'as pas encore été confronté au problème, il est normal de ne pas saisir leur utilité.

Même s'il est utile de les connaître (ça améliore ta culture générale de la programmation), ce n'est pas impératif dans tous les cas. Tu peux par exemple utiliser des iterators sans connaître le détail du patter Iterator.

Ceci dit, dans le cas du développement Web, certains patterns sont plus utiles à connaître que d'autres, parce qu'ils correspondent à des problèmes que tu as déjà ou que tu auras à rencontrer. Tu les trouveras dans l'ouvrage référence "Patterns of Enterprise Application Architecture" de M. Fowler (une référence rapide des patterns se trouve ici: http://martinfowler.com/eaaCatalog/). Ces patterns 'Entreprise" te seront plus utiles que les autres.

Autre conseils: consulte le site dans ma signature: PHP The Right way. C'est la référence en matière de bonnes pratiques.

La majorité des tutoriels qu'on trouve en ligne se référent à des techniques d'il y a 5 ans (voire pire). PHP a fait bien du chemin depuis et n'a plus rien à voir avec le PHP d'avant. Apprends à utiliser composer pour gérer tes dépendances et ton autoloading, n'utilise plus jamais l'extension mysql, écris des tests pour tes classes et méthodes.

[MonsieurPoulet]

Merci pour vos réponses, le site des bonnes pratiques et le github des design patterns sont très intéressants.

Avant de me lancer dans l'apprentissage d'un Framework complet, je pense développer le mien, un genre de micro-framework adapté à mon usage. C'est la raison pour laquelle je fais un détour par les patterns et que je mets les mains dans le cambouis - à mon avis la seule façon d'apprendre des choses.

A votre avis, quelle serait la forme la plus adaptée pour raconter mes déboires et poser mes questions dans la création de ce micro-framework ? Un topic unique (genre celui-ci) assorti d'un github ? Ou bien un topic/une question ?

[papajoker]

Avant de me lancer dans l'apprentissage d'un Framework complet, je pense développer le mien, un genre de micro-framework adapté à mon usage. C'est la raison pour laquelle je fais un détour par les patterns et que je mets les mains dans le cambouis - à mon avis la seule façon d'apprendre des choses.

NON

Le design pattern est une solution a un problème donné. Toi tu vas te créer des problèmes pour les utiliser

j'ai débuté oops en créant mon framework php. Résultat que d'années perdues !
Mon framework fonctionnait très bien mais il était d'un pauvreté navrante, simplement a l'époque je ne pouvais pas m'en rendre compte. Vouloir développer ce qui est le plus difficile (Framework MVC) lorsque l'on est "débutant" est une aberration.

Si tu désires faire les choses bien , aujourd'hui il y a un minimum psr-2:

https://github.com/php-fig/fig-standards (version fr : https://github.com/php-fig/fig-stand...er/accepted/fr)

voici un micro-framework qui le respecte, construit avec les bons designs patterns : https://github.com/auraphp/Aura.Framework
C'est un micro-framework(exemple), donc ce que tu devrais pondre si les designs sont bien assimilés.

un rapide coup d'oeil sur les sources devrait te faire comprendre le long chemin a faire.

ps : Les design patterns ne sont pas une religion.

C'est un modele a un probleme particulier, c'est un patron qui permet de normaliser la réponse. Sa plus grande utilité est le partage de sources : si avec un collègue tu as le même framework, et utilise les mêmes designs alors tu a l'impression de voir ton source avec celui de ton collègue. Cette normalisation a un coût, et n'est pas obligatoirement la bonne solution. C'est une solution d'entreprise pour une meilleure maintenance du code. Pour le particulier beaucoup de très bons designs patterns sont à proscrire
Bien sur, avec GitHub, les avantages sont évidents, car la nous sommes dans le monde du partage (de code).

[MonsieurPoulet]

C'est pour ça que j'ai dit "avant de me lancer dans l'apprentissage d'un framework".

L'idée c'est pas de faire quelque chose d'exhaustif ni d'atteindre la complexité d'un vrai framework, mais plus de m'éduquer en passant en revue les best practice de ces derniers (les PSR-0, PSR-1 etc., par exemple, je ne connaissais pas et c'est intéressant).

Il n'y a pas beaucoup de pilotes qui construisent leur voiture, mais certains savent quand même ce qu'il y a sous le capot, et je voudrais faire partie de ceux-là

Je reviendrai bien vite à Laravel, ne serait-ce que pour rentabiliser le bouquin Code Bright acheté avec mes deniers

[papajoker]

L'idée c'est pas de faire quelque chose d'exhaustif ni d'atteindre la complexité d'un vrai framework, mais plus de m'éduquer en passant en revue les best practice de ces derniers (les PSR-0, PSR-1 etc., par exemple, je ne connaissais pas et c'est intéressant).

Pour moi, designs pattern, psr, c'est les choses a connaitre pour faire un bon choix de Framework (ou librairie); Bon maintenant tous les + grand cms et framework php sont psr mais je vais pas m'en plaindre.
PSR est maintenant obligatoire grâce a github (connexions des librairies et partage du code)

Il n'y a pas beaucoup de pilotes qui construisent leur voiture, mais certains savent quand même ce qu'il y a sous le capot, et je voudrais faire partie de ceux-là

Construire une voiture sans en avoir vu rouler (j'ai vu dans ta démarche)

Je reviendrai bien vite à Laravel, ne serait-ce que pour rentabiliser le bouquin Code Bright acheté avec mes deniers

pour moi, Code Bright n'est que la documentation avec des exemples. Juste un guide d'utilisation. Après lorsque l'on utilise un framework, de temps en temps on a un travail spécifique et la on va voir le code source, et c'est la seule façon de voir ce qu'il y a sous le capot : par dose + ou - homéopathiques.

[Tsilefy]

Je me joins à Papajoker. Si tu débutes en OOP, ça ne sert à rien de vouloir réinventer la roue, apprends d'abord à conduire. Apprends comme le code s'organise, quelles sont les relations entre les différents composants, comment "ça marche" sans forcément ouvrir le capot.

Je ne vois pas d'intérêt à partir de zéro pour apprendre, alors qu'on peut se jucher sur les épaules des géants et accélerer considérablement son apprentissage. Après, une fois que tu maîtrises bien les fondamentaux, tu auras peut-être envie de te plonger dans le cambouis (encore que c'est plus intéressant de créer quelque chose de nouveau que de refaire des choses déjà vues et revues). Quitte à faire des erreurs pour apprendre, fais-les sur des trucs nouveaux.

Après, ce n'est que mon avis :-)

Si tu veux comprendre comment marche un Framework de l'intérieur sans réinventer la roue, suis ces articles:
http://fabien.potencier.org/article/...ponents-part-1.
Tu apprendras mille fois plus de choses avec ça qu'en créant toi-même un millionième "Framework MVC" dans ton coin.

[MonsieurPoulet]

Vous avez sans doute raison.

Je vais postponer le cambouis et commencer par le framework !