#1 Le 04/01/2012, à 13:09
- Morgiver
Discussion autour du concept de la POO
Bonjour,
Voilà bon, la POO, j'ai mi les pied dans le plat et c'est pas si simple que ça.
Alors au lieu de faire tout plein de post la concernant, je crois qu'un post dédié à la POO en PHP est une meilleure solution.
Le but de ce post est évidemment que les chacun puisse tenter de parler de ce qu'il connait pour tester ses connaissance, affiner sa compréhension de différent sujet, car au delà de la programmation, on se retrouve la plus part du temps face à des concept sur lesquels ils faut pouvoir mettre des mots soit même.
Et je vais lancer cette discussion par les objets (tiens donc 
).
Plus j'avance dans le développement et plus je lis des trucs sur la POO, je me dis qu'au final, avant de penser application, il faut penser objet. Un peu comme construire une maison, il faut tout plein d'objets pour la construire. Mais ces objets ne servent pas forcément QUE à la construction d'une maison, on peut les assemblé à d'autres objets pour faire bien d'autres choses.
Mais ces objets sont eux aussi, ou peuvent être composé d'une myriades d'objets différents.
Mais je me demande quand même où est la limite. Dois-je créer un objet par idée ? En créant un objet, dois-je forcément m'assurer que je ne peux pas le réduire encore à plusieurs autres petits objets ? Au final je pourrais me retrouver avec des millier d'objets, ça deviendrait plutôt complexe à gérer, non ?
Comment gérez vous ce coté du développement ?
nb: Ça me fait penser à la composition de la vie, l'homme, son corps, ses organes, ses parties d'organes, ses cellule, ses atomes, ses ceci et cela...
Morgiver
Dernière modification par Morgiver (Le 05/01/2012, à 12:40)
Hors ligne
#2 Le 04/01/2012, à 15:18
- Mindiell
Re : Discussion autour du concept de la POO
Facile (hu hu hu),
Tu as ton objet application (grosso modo), et après, s'il devient lourd tu le segmentes.... C'est tout.
Grosso modo, depuis le temps que je développe, j'ai appris quelques trucs :
- Rester simple
- Faire ce qu'il y a à faire (et non pas des tas de choses à côté)
Le meilleur exemple serait un moteur 3D pour un jeu vidéo : les gens vont passer des années dessus pour faire un truc époustouflant. A côté de ça, le gars tout seul qui a développé le jeu avec un moteur repris ou pas totalement fini, il a un vrai jeu qui tourne.
Applique toi ça tout le temps :
- En ai-je vraiment besoin ?
- Pourrais-je le réutiliser ? Si oui, dans combien de temps ?
Un autre exemple si tu fais plusieurs projets (parce que l'objet ça sert à maintenir plus facilement, mais aussi à faire évoluer, et à réutiliser), ou si tu veux faire évoluer ton projet, il faut avoir une approche objet, un modèle MVC. A partir de là, tu peux faire des trucs "un peu crade", tu pourras toujours revenir dessus et améliorer quand le reste marchera.
Tu utilises un framework pour développer ? Ca peut avoir quelques avantages intéressants (j'utilise jelix, php only, et assez puissant personnellement).
PS: Ah oui, sinon la POO n'a pas forcément quelque chose de particulier en PHP. Ca devrait rester de la POO, quel que soit le langage...
Hors ligne
#3 Le 04/01/2012, à 15:58
- Smon
Re : Discussion autour du concept de la POO
Le concept d'objet n'est pas facile à expliquer parce qu'on le comprend un peu tous différemment.
Mais en gros voit ça un peu comme une façon de t'organiser.
Un utilisateur peut être un objet.
Un produit peut être un objet.
Une vente peut être un objet.
Un commentaire de blog peut être un objet.
Etc.
Pour savoir jusqu'à quel point tu vas devoir "objetiser" ça va dépendre de tes besoins.
Par exemple, si pour un utilisateur tu as besoin de définir une couleur pour ses yeux, tu vas juste ajouter un attribut à l'utilisateur.
Par contre si pour toi un œil, c'est la taille du globe, les degrés de couleur de l'iris, la taille de la cornée, toussa, ben tu vas créer l'objet œil.
Le tout, c'est de savoir du quoi tu as besoin pour ton projet.
Hors ligne
#4 Le 04/01/2012, à 16:17
- Morgiver
Re : Discussion autour du concept de la POO
On s'y perd quand même vachement fort, vu qu'on peut tout objetiser.
D'ailleurs c'est ce dont je parlais dans mon précédent post, d'objetiser le CRUD et automatiser la construction des requêtes SQL pour pas devoir les ré-écrire.
Au final un objet doit pouvoir être réutiliser le plus souvent possible, après comme on l'a dit, à long terme ça peut représenter des inconvénients majeur.
D'une certaine manière, j'imagine que l'objet ultime c'est celui qu'on peut réutiliser sans arrêt et sur un long terme, sans pour autant y apporter des modification majeur qui oblige de changer tout le code d'une application. Voir mieux, qu'on puisse le faire évoluer en y apportant de grosse modification sans pour autant changer le code du reste de l'application.
L'utopie quoi 
Cela dit, mon envie de coder un gestionnaire de site ultra léger avec du code qui se réutilise tout temps reste dans ma tête, juste pour le challenge du truc 
Hors ligne
#5 Le 04/01/2012, à 17:32
- Mindiell
Re : Discussion autour du concept de la POO
Va donc filer un oeil sur ce framework (http://www.jelix.org/), il répond, à mon avis, à tes attentes. Et grâce à ça, tu vas gagner un temps fou pour faire de "vraies choses"...
Non, parce que réinventer le CRUD et Cie, c'est intéressant, mais, à terme, tu auras moins d'expérience que certains frameworks qui sont là depuis longtemps et qui en ont vu d'autres 
Hors ligne
#6 Le 04/01/2012, à 17:57
- Smon
Re : Discussion autour du concept de la POO
Zend Framework c'est le top.
Hors ligne
#7 Le 05/01/2012, à 11:32
- Morgiver
Re : Discussion autour du concept de la POO
En fait j'attends pas grand chose, je voulais juste causer de concept pour pouvoir exprimer ce que j'apprends et pouvoir en parler avec d'autres qui connaissent mieux que moi.
C'est ma façon de m'évaluer, du moins en partie.
Le but n'étant pas de réinventé la roue, mais de passer par les étapes de sa conception pour mieux comprendre son fonctionnement.
Hors ligne
#8 Le 05/01/2012, à 12:35
- Jules Petibidon
Re : Discussion autour du concept de la POO
Un truc lorsqu'on découvre la POO, c'est qu'on a tendance à y voir une fin en soi, alors que ce n'est qu'un moyen de planifier et organiser son développement.
Pour bien comprendre le pourquoi et le comment de la POO, il est intéressant d'étudier un minimum UML, ça permet de voir l'intérêt de la modélisation objet pour faciliter le développement. Le gros problème, c'est surtout qu'apprendre UML, c'est super chiant.
Et sinon pour entrevoir un peu l'intérêt de l'objet, PHP n'est pas super adapté. Non pas que l'objet en PHP soit mauvais, il est juste optionnel et le langage en lui même ne l'utilise quasiment pas. Un petit passage par Java, ou plus simplement Python ou Ruby permettent de se faire un peu plus d'idées sur le fonctionnement du truc.
Hors ligne
#9 Le 05/01/2012, à 12:40
- Morgiver
Re : Discussion autour du concept de la POO
[...]Et sinon pour entrevoir un peu l'intérêt de l'objet, PHP n'est pas super adapté. Non pas que l'objet en PHP soit mauvais, il est juste optionnel et le langage en lui même ne l'utilise quasiment pas. Un petit passage par Java, ou plus simplement Python ou Ruby permettent de se faire un peu plus d'idées sur le fonctionnement du truc.
Tiens ça par contre je ne m'y attendais pas.
Javascript peu être orienté objet, non ? est-ce qu'il est suffisamment adapté ?
Hors ligne
#10 Le 05/01/2012, à 12:42
- Smon
Re : Discussion autour du concept de la POO
Exactement, la POO reste un outil et permet d'organiser efficacement son code.
Hors ligne
#11 Le 05/01/2012, à 12:48
- Mindiell
Re : Discussion autour du concept de la POO
Non, c'est la même chose que PHP : tu peux utiliser les notions d'objet, mais il n'est pas orienté objet au départ, tu peux donc "louper" ou mal comprendre certaines choses.
Pour les étapes de la conception, comme je te l'a idit plus haut, je préfère (avec un peu d'expérience maintenant) largement commencer à coder la plupart des choses en dur, et sans trop d'objets. Après, au fur et à mesure que j'ajoute des fonctionnalités ou bien que je factorise le code, j'ajoute les objets dont j'ai besoin. Bien entendu, en utilisant un framework (Zend, Symfony, jelix, CakePHP, etc... on évite les trolls ), tu as une vision MVC de ton application qui t'aide à ne pas tout refaire à chaque fois.
Je suis actuellement sur une appli web justement, et j'ai une partie de code en dur sur ma première page que je vais transvaser sur un objet. Mais, au pire, ça marche comme ça et c'est utilisable en l'état. La mise en objet va me servir à utiliser les mêmes fonctionnalités sur d'autres pages de manière simplifiée et de factoriser les besoins (les mettre à un seul endroit).
Hors ligne
#12 Le 05/01/2012, à 13:02
- Morgiver
Re : Discussion autour du concept de la POO
Ha ouais pas con de travailler en dur en premier lieu
J'imagine que ça permet de pas se perdre lors de la conception des objets, vu que tout est déjà coder, ça évite de se disperser non ?
Un peu comme un dessinateur qui fera le début de son dessin au crayon, en tapant les grandes lignes, les premières ombres, etc.. puis passera à quelque chose de plus net et beaucoup plus précis, avec des couleurs, d'autres détails, etc...
Je commence à mieux comprendre le coté "organisation du code".
Hors ligne
#13 Le 05/01/2012, à 13:13
- Smon
Re : Discussion autour du concept de la POO
Pas d'accord du tout. Ton application doit être pensée objet, sinon c'est juste du procédural avec un peu d'objet dedans.
Le but c'est d'utiliser au maximum les design pattern dès la conception, pas d'essayer de les intégrer après coup. Va adapter ton site procédural à un modèle MVC une fois qu'il est fait, tu vas te marrer.
Hors ligne
#14 Le 05/01/2012, à 14:19
- Mindiell
Re : Discussion autour du concept de la POO
Smon> Si tu avais mieux lu mon post, tu verrais que je conseille l'utilisation d'un Framework et donc une vision MVC
Mais cela ne doit pas empêcher de créer un objet un peu fourre-tout que l'on peut découper en plus petits objets par la suite et suivant des besoins "réels" : On crée uniquement les objets utiles et pas une éspèce d'architecture d'ensemble d'objets pas forcément bien pensés dès le début et qui seront surement sujet à modifications par la suite.
C'est ma philosophie perso de dév, un peu basée sur le KISS (Keept It Simple, Stupid) et l'XP (Xtrem PRogramming).
Hors ligne
#15 Le 05/01/2012, à 14:24
- Smon
Re : Discussion autour du concept de la POO
Je connais cette philosophie. Je la subis tous les jours avec un fameux "God object" qui a été créé par un de mes devs, qui a grossi au fil du temps et qui n'a jamais été découpé.
Résultat : 8000 lignes de codes et le gros bordel.
Heureusement qu'on a des IDE qui cherchent à notre place, sinon on serait mal.
Le prochain dev qui me fait ça, j'imprime ses 8000 lignes de code en Deja Vu Extra Bold taille 56 et je lui fais bouffer. Et sans mayonnaise ! 
Hors ligne
#16 Le 05/01/2012, à 14:30
- Morgiver
Re : Discussion autour du concept de la POO
les 8000 lignes dans une page ? oO'
Hors ligne
#17 Le 05/01/2012, à 14:33
- Smon
Re : Discussion autour du concept de la POO
Oui, c'est le résultat de la méthode : on fait tout en dur, on séparera plus tard.
Parce que dans la réalité, plus tard = jamais
Hors ligne
#18 Le 05/01/2012, à 14:56
- Mindiell
Re : Discussion autour du concept de la POO
Parce que dans Ta réalité, plus tard = jamais
Parce que dans la mienne, disons à mon niveau, en tant que développeur, la factorisation et le découpage se font en permanence, ça peut rester ainsi de quelques minutes à quelques jours grand maximum.
De plus, Morgiver est dans une optique projet perso je crois, c'est pas la même chose même si c'est important defaire propre...
Hors ligne
#19 Le 05/01/2012, à 15:31
- Morgiver
Re : Discussion autour du concept de la POO
Lawl, un fichier source de 8000 lignes, faut être fou pour s'amuser à fouiller dedans.
Depuis que j'ai commencer la programmation on m'a toujours dit "Diviser pour mieux régner, écrit plusieurs pages au lieu de tout mettre dans une seule".
Et depuis le début un de mes objectif c'est d'apprendre à faire du code ré-utilisable le plus souvent possible. Quand j'ai commencer à découvrir la POO, je trouvais génial le concept de pouvoir faire quelque chose que j'aurais pas besoin de ré-écrire plus tard et que je pourrais utiliser dans différentes applications. Gain de temps énorme, c'est surtout à ça que je pensais. Mais ça c'est parce que je suis souvent du genre à aller trop vite, alors faut que je me freine
Hors ligne
#20 Le 05/01/2012, à 15:34
- :!pakman
Re : Discussion autour du concept de la POO
C'est clair qu'au niveau pro, ça fait tâche
...
Hors ligne
#21 Le 05/01/2012, à 15:47
- Smon
Re : Discussion autour du concept de la POO
Je te le fais pas dire.
[troll]De toutes façon les devs C# c'est tous des tâches, c'est pas chez les vrais devs PHP qu'on verrai ça[/troll]
(oui c'est un dev C# qui m'a fait ça)
Dernière modification par Smon (Le 05/01/2012, à 15:47)
Hors ligne
#22 Le 05/01/2012, à 16:01
- Morgiver
Re : Discussion autour du concept de la POO
La POO n'est donc pas à proprement parler un concept qui permet de réduire de façon significative le code à écrire (j'entend par là le code qui se répète régulièrement).
On m'a toujours dit que les développeur étaient des grosses feignasses qui font des fonctions pour tout et n'importe quoi, du moment que ça leur permettent de gagner du temps et de l'énergie
Je me suis beaucoup "amusé" à écrire des requêtes SQL quand j'apprenais (et je continue hein ! Grâce à vous entre autre, merci), et par la suite, quel plaisir de pouvoir envoyer un tableau de champ et une ou deux instructions à un objet qui génère la requête et qui te l'exécute directement. Trop l'impression de coder beaucoup plus vite vu que certaine chose était faite automatiquement.
J'ai aussi un objet qui en fonction des champs et de leur type, te génère un formulaire. Bon, le truc juste un peu chiant c'était d'écrire le tableau, mais au final le résultat était pas mal
Bon le seul truc c'est que le code était encore bordélique, je venais de commencer la POO.
Je sais Smon Faut écrire les TOUT les manager xD
Hors ligne
#23 Le 05/01/2012, à 16:58
- yohann
Re : Discussion autour du concept de la POO
Je vais peut être être un peu HS, mais un truc que j'essaie d'appliquer c'est la règle des 100 lignes :
qui est pour moi valable tant en OO qu'en procédural: un fichier fait + de 100 ligne => split
en programmation objet ça se traduit par: éviter d'avoir des classes de plus d'une centaine de lignes.
ensuite en général on peu plus ou moins partir de l'analyse Merise pour définir les objets (c'est d'ailleurs peu ou proue ce que fait pour toi un ORM tel que doctrine en PHP ou sqlAlchemy en Python)
Merise et la règle de 100 ligne pour spliter un objet qui devient trop gros font déjà une bonne base.
ensuite ce qui est très très intéressant en objet c'est évidement la maintenance, mais aussi la facilité d'utilisation du codes des autres.
Et je plussoie grandement Smon sur l'utilisation des design pattern (meme si on ne peut pas non plus les considérer comme une fin en soi)
un exemple concret pour un log de facturation:
2 type d'objets:
les objets "métier":
- client
- factures
- ligne de facture
- utilisateur
les objets "helper" (la plupart du temps ils sont fourni par le framwork ou récupérer dans un lib externe mais rien ne t'empeche de les créer)
- PersistantObject (nom inventé, il s'agit d'une classe abstraite dont vont hérité les objets persistant pour faciliter l'enregistrement / chargement) la plupart du temps c'est fourni par le framework ou l'ORM.
- Controller (si tu as un framwork mvc)
- Form (pour créer facilement un formulaire)
- Une tripoté d'autre objets réutilisables (couche d'abstraction BDD par exemple qui est utilisé par la classe PersistantObject)
De ma faible expérience, les objets réutilisable sont souvent ceux de la seconde catégorie, et il est souvent inutile de les créer, il suffit de les reprendre et de trouver comment s'en servir.
Les objets métier quand à eux change d'une appli a l'autre donc par la peine de faire de l'over ingénierie a vouloir les rendre polyvalent et adaptable
Enfin je précise que ce que je dit est valable dans le contexte de petite applis pas forcément en général
c'était mes 2 ct
j.vachez, le génie du net | Soirées jeux sur Lyon | 441
++++++++++[>+++++++>++++++++++>+++<<<-]>++.>+.+++++++
..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.
Hors ligne
#24 Le 05/01/2012, à 17:12
- Smon
Re : Discussion autour du concept de la POO
La règle des 100 lignes n'est pas non plus une fin en soi ... Faut pas splitter juste pour le plaisir de ne pas dépasser les 100 ligne.
Hors ligne
#25 Le 05/01/2012, à 17:24
- Mindiell
Re : Discussion autour du concept de la POO
On m'a toujours dit que les développeur étaient des grosses feignasses qui font des fonctions pour tout et n'importe quoi, du moment que ça leur permettent de gagner du temps et de l'énergie
C'est comme tout : Tu as deux types de feignasse...
La feignasse de Smon qui ne prend pas le temps de factoriser son code (et je suppose qu'il n'y a pas de commentaire en plus).
Les autres qui prennent le temps de faire des objets pas trop crades et donc réutilisables.
Le plus gros souci du terme ré-utilisable, c'est que les gens comme toi (Morgiver) ont tendance à l'appliquer à la lettre.
Le "truc" étant de faire un objet pour ton appli, et si demain tu as besoin du même genre de choses il faut le reprendre et peut-être légèrement l'adapter, ça reste un bon gain de temps.
Mais le souci, c'est que les gens ont tendance à faire des objets qui sont capabes de tout, ce qui n'existe pas, et perdent beaucoup de temps sans aucun résultat...
Hors ligne