En toute indiscrétion, où as-tu appris le dev web? et quand?Envoyé par Kevin-lourenco
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
En toute indiscrétion, où as-tu appris le dev web? et quand?
J'ai appris de multiple façons différentes, formation, site internet, cursus scolaire, livres, expérience en entreprise.
J'ai commencé il y à 4 ans, j'en est aujourd'hui 21.
Ce n'est pas indiscret à partir du moment où tu demandes par curiosité et non pour m'attaquer sur ce que tu jugerais une faiblesse
Petit exemple vécu
Après avoir fait souffrir mes élèves dans la programmation purédure en C traditionnel, en particulier dans les manipulations des chaînes de caractères ce qui est un vrai supplice algorithmique, je leur ai montré comment on pouvait construire un objet "Chaine" (je l'ai appelé comme ça puisqu'il y a le tout-mâché String), avec les constructeurs, les destructeurs, l'opérateur '+' pour l'accrochage des wagons, etc. Plus d'autres petits exemples de ce niveau. L'intérêt pour eux fut évident, d'autant que je leur ai montré qu'ils pouvaient alors faire leurs classes comme ils le voulaient avec beaucoup moins de contraintes qu'en C traditionnel.
"Toute l'histoire de l'informatique n'a été que l'histoire des systèmes d'exploitations" (Le Manifeste du PC)
Pourquoi, pourquoi, pourquoi…
1) pourquoi S.Jobs connait la POO ?
La programmation orienté objet à été « élaborée » par Ole-Johan Dahl et Kristen Nygaard au début des années 60 puis « aboutie » par Alan Kay au Xerox PARC.
La suite beaucoup la connaissent : Steve jobs en visite au PARC découvre les travaux d’ Alan Kay qu’il finira enbaucher chez Apple. Entre temps Apple fabirque une premiere machine Smalltalk (le Lisa), puis par la suite les Macintosh, qui sont devenus par la suite une source d’inspiration du Système Windows et le ras de marée culturel qu’est devenu la micro informatique…
Donc voila pourquoi Steve Jobs à bien pigé ce qu’était la POO, et surtout la "vendre".
2) pourquoi la presse interroge S.Jobs sur la POO ?
L’interview date de 1994, pour marquer l’anniversaire des 10ans du premier Macintosh ; c’est un peu logique d’interviewer S.Jobs. et si le sujet dévie sur la programmation objet c’est parce qu’elle à fait partie de l’ADN du Mac.
3) pourquoi on reparle « encore » de S.Jobs aujourd’hui ?
Je comprends que cela puisse en agacer plus d’un, mais c’est comme ça. S.Jobs à tout fait pour devenir une icône mondiale, on risque d’en parler encore longtemps.
C’est d’ailleurs ce pourquoi aussi sort un film sur sa vie en ce moment, et qui "justifie" que Rolling Stone ressorte cette veille interview aujourd’hui, histoire d’être dans le buzz de l’audimat…
Mais ce film semble faire un flop ; j’imagine que c’est une consolation pour certains.
Quand aux diverses explications sur la nature de la POO, je vois que cela reste toujours obscur pour beaucoup...
«La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode
Rappelons que je suis en PHP.
Il y a sûrement beaucoup plus de contraintes à rester en procédural au niveau d'un language compilé que d'un language interprété.
Quand je code en Java (language compilé) je programme, comme vous, en orienté objet.
Je ne me le permettrais pasJ'ai appris de multiple façons différentes, formation, site internet, cursus scolaire, livres, expérience en entreprise.
J'ai commencé il y à 4 ans, j'en est aujourd'hui 21.
Ce n'est pas indiscret à partir du moment où tu demandes par curiosité et non pour m'attaquer sur ce que tu jugerais une faiblesse
Cependant, ton comportement me fait penser à un citation de Abraham Maslow : "Si le seul outil que vous avez est un marteau, vous verrez tout problème comme un clou."
A mon avis tu maitrises uniquement la programmation procédurale en PHP et toutes les solutions qui te semblent les meilleurs sont dans ce qu'on appelle ta zone de confort.
Tu es encore un débutant, quand tout un forum d'initiés "s'acharne" sur toi pour te montrer et démontrer que tu as tort (de façon pédagogique ou non, je salue d'ailleurs la patience d'Ipnose pour son exemple particulièrement démonstratif), tu devrais prendre du recul et essayer de comprendre leurs propos
Je ne peux que te conseiller de découvrir le monde de l'Orienté Objet, il résous au final beaucoup plus de problème qu'il n'en crée
A aucun moment je n ai dis que ma solution était mieux bien au contraire ! J'ai un résonnement logique.
Si j'ai un marteau, et qu on me propose un nouvelle outil je veux pouvoir directement visualiser que l'outil améliorera considérablement ma productivité.
Si l'outil est aussi simple qu'un marteau plus solide avec un meilleur manche, je n'aurais aucun mal à me dire "en effet c'est mieux"
Mais là on me propose de construire une machine complètement différente pour faire la même finalité. Mais le fait elle mieux plus et vite ?
Si c'est le cas alors oui, je construisais ce nouvelle outil.
Mais si le gain est trop maigre par rapport à l effort de construction, alors ce n'est pas la peine.
D'où ma remarque, je verrais quand je créerait un nouveau projet, l actuel étant déjà trop avancé pour faire ce changement.
Je te souhaite de commencer un nouveau projet bientôt alors. les exemples précédents n'ont pas l'air de te convaincre de l'avantage énorme de modularité de l'Orienté Objet...
Peut être n'as-tu jamais eu a faire de maintenance sur un projet ou des évolutions hors conception originale?
Le projet actuel est un site e-commerce mis en ligne et amélioré quotidiennement, j'espère que cela réponds à ta question
Je trouve que la définition de Steve Jobs va très bien aussi à la programmation procédurale.
"Je trouve que la définition de Steve Jobs va très bien aussi à la programmation procédurale."
Donc je ne suis pas le seul à penser cela.
Vu que apparaement personne n'arrive à avoir une définition plus claire et ciblé de ce que permet vraiment l'objet, je m'en vais apprendre la POO pour me forger ma propre opinion.
@ Kevin-lourenco
La, par rapport à la logique de la POO : t'es completement à l'envers:mesage 25 => Merci ! Mais bon tout cas on peut le faire avec des variables passées en référence ?
mesage 43 => Donc en soit je n ai pas totalement tord quand je dis q'une fonction est en soit une conception objet
...
la logique de la POO veut que les objets aient leurs actions propres.
Donc dans ton cas, passer une variable en référence (par pointeur sur la variable) [dans une fonction] c'est du procédural.
en Objet ta "variable en référence" devrait être un objet qui possede en lui même la (ou les) fonctions qu'il doit réaliser.
Mais pour être plus précis encore, un objet est en lui même une abstraction, il n'existe réellement que lorsqu'il est instancié (avec ses valeurs).
Pour prendre un exemple classique en programmation (et en restant dans l'univers des débuts de SmallTalk)
Un des Objet les plus simple à apréhender pour un dev : une fenetre.
Une fenetre c'est un objet présent sur l'IHM, elle est composée d'une barre de titre, d'une case de fermeture, de redimensionnement; Il y une partie libre pour le contenu, etc...
Pour le developpeur la création d'une fenetre dans l'IHM se fait par une simple instanciation, il ecrit un code dans le genre
MaFenetre1 = new Fenetre(liste des particularismes voulus pour cette première fenêtre);
MaFenetre2 = new Fenetre(liste des particularismes voulus pour cette seconde fenêtre);
MaFenetre3 = new Fenetre(liste des particularismes voulus pour cette troisième fenêtre);
Puis par la suite y lui demander de réaliser ses propres "fonctions" (on parle de méthodes) comme par exemple
MaFenetre1.changCouleurFond(Orange);
MaFenetre3.positionneToi(enHautaGauche);
«La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode
Performances médiocres et surconsommation en flèche.
Et reconnaissons le, avoir des milliards d'instances d'objets dans tout les coins, c'est pas gérable.
Depuis on à inventé les bases noSQL et le Big data, c'est beaucoup plus simple et efficace.
«La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode
J aime beaucoup ta phrase j ai l impression d y voir plus claire:
"en Objet ta "variable en référence" devrait être un objet qui possede en lui même la (ou les) fonctions qu'il doit réaliser."
Mais au fond que ce soit la fenêtre qui est "autonome" ou que ce soit une fonction principale qui contrôle la fenêtre, cela change beaucoup de chose ?
Je m'explique un peu plus, dans les langages comme Pascal ou une procédure ou fonction peut englober tout un petit monde de procédures et fonctions imbriquées, une telle procédure peut très bien avoir un énorme savoir faire.
Pour les langages qui n'acceptent pas l'imbrication, les librairies peuvent suppléer.
Ben ça change tout, et à plein de niveaux
_par exemple en mémoire :
chaque objet "fenêtre" à ses propres contenus (ou variables) ce qui évite d'avoir de gérer autant de variables pour chaque fenetre comme par exemple dans un tableau, alors que si une fenetre deviens inutile, toutes la place occupée en mémoire est récupérée
_par exemple en validation du code:
Comme chaque objet à ses propres méthodes (fonctions qui lui sont propres) impossible de lui appliquer par erreur d'écriture une fonction qu'il ne peut pas faire
_la compréhension du code, avec les valeurs contextuelles et encapsulées pour chaque objet,
il y a aussi l'héritage: créer un nouvel objet à partir d'un premier objet, mais en lui ajoutant des méthodes, variables, etc...
Ce qui permet par la suite de gérer par polymorphisme, et même pour certains langages faire de la surcharge d'opérateurs, autant de choses qui permettent d'avoir un code plus concis et plus clair....
En POO on maitrise plus facilement les programmations gigantesques, on peut plus facilement assigner le travail par équipe par tranches d'objets,
Dans le dev on commence généralement à créer le code par le "haut" cad les grandes fonctionnalités, quitte à faire des objets avec un embryon de code, pour bien maitriser la vue d'ensemble, pour ensuite pouvoir affiner les détails des objets de bas niveaux...
Les tests unitaire ont commencés avec les objets, et sont bien plus simple à mettre en œuvre en POO qu'en procédural, surtout quand on remonte dans la complexité et les imbrications d'objets, ce qui devient vite un enfer en procédural,
La POO est aussi tres pratique quand on veut récupérer des objets pour un projet différent, ce qui permet de gagner pas mal de temps et surtout de fiabilité, alors qu'en procédural ça devient vite un cauchemars, pour peu qu'on oublie une petite variable peu utilisée dans un coin...
Il existe même des boites spécialisées qui proposent des objets tout faits..
alors non, si la POO à été "inventée" ce n'est pas uniquement pour un simple exercice intellectuel, mais bien parce qu'il a la une réelle utilité et un besoin vital.
Même le langage ADA , qui à la base était censé être un aboutissement sur" l'art de programmer" à du être remanier pour devenir un langage Objet...
«La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode
Merci à vous deux d avoir pris le temps et avoir su m'éclairer sur la POO, cette fois j'ai plus facilement pu faire le lien entre les bénéfices apportés et les fois où j'ai rencontré des problèmes en procédural
C est sur que de cette manière, cela vaut vraiment le coup de "sortir de ma zone de confort", pour à peu près tous les points mentionnées précédemment, en particulier la question de mémoire, la réutilisation d'objet et la simplification des tests unitaires
C'est 100 000 euros facilement gagné en fait...Maintenant la vraie question à 100 000 euros : peux-tu faire aussi modulable et structuré que ça avec une approche procédurale ?
(Désolé pour le code, ce n’est pas du PHP –pas ma tasse de thé– mais j’ose espérer que le code est lisible).
Le fait qu'un code soit modulable ou structuré n'est pas une question d'objet. La pertinence quant au choix du paradigme dépend de l'approche choisie pour la résolution un problème. Par exemple l'objet n'est pas spécialement adapté pour le traitement de flux de donné ou la construction d'un jeu de donné mais est très pertinent pour gérer des structures de données persistantes stockées en mémoire vivant indépendamment. L’inconvénient avec la mode objet vient surtout de la confusion entre le paradigme lui même et critères transversaux sont la modularité, la structure, etc.
Il est en fait relativement aisé de faire plus modulaire que votre exemple dans la mesure ou vous avez choisit de créer une dépendance entre un véhicule et son réservoir, voir entre le réservoir et la méthode de remplissage...
Exemple ...
On commence par définir les structures de données de base.
On crée des fonctions d'initialisation qui joueront un rôle équivalent au constructeur et au système d'héritage...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
On se retrouve grosso merdo avec la modularité proche de cette de votre exemple.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
31
32
33
34function nouvelle_voiture($vehicule) { $voiture = $vehicule ; $voiture['nombre_porte'] = 4 ; $voiture['nombre_place'] = 4 ; $voiture['reservoir']['capacite'] = 50 ; return $voiture ; } function nouvelle_moto($vehicule) { $moto = $vehicule ; $moto['nombre_porte'] = 0 ; $moto['nombre_place'] = 2 ; $moto['reservoir']['capacite'] = 30 ; return $moto ; } function nouvelle_monospace($vehicule) { $mspace = $vehicule ; $mspace['nombre_porte'] = 4 ; $mspace['nombre_place'] = 8 ; $mspace['reservoir']['capacite'] = 80 ; return $mspace ; } function nouvelle_station_service($station) { $station['carburant'] = 'sans plomb' ; $station['reserve'] = 1000 ; $station['remplir'] = function(){} }
Comme a la différence de votre exemple je n'ai pas lié la méthode de remplissage à la station de service et au réservoir, je peux créer une autre station de service et la bidouiller technique pour faire le plein à chaud...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16$instances = array(); $instances['voiture1'] = nouvelle_voiture($vehicule); $instances['voiture2'] = nouvelle_voiture($vehicule); $instances['moto1'] = nouvelle_moto($vehicule); $instances['moto2'] = nouvelle_moto($vehicule); $instances['monospace'] = nouvelle_monospace($vehicule); $bernard_store = nouvelle_station_service($station); foreach ($instances as $name=>$instance) { $instance.avancer(); if($name=='monospace' && $instance['reservoir']['niveau']<10) $bernard_store['remplir']($instance); etc... }
L'utilisation de closures ou de callback permet de gagner en souplesse et en modularité. Ce sont des techniques transversales utilisables aussi bien en POO que dans d'autres paradigme. En fait la POO impose une structure qui certes est plus facile a comprendre pour un autre développeur familiarisé avec la POO mais qui oblige a passer par des design pattern complexe pour faire ce que l'on fait naturellement avec du procédural/impératif. Par exemple l'encapsulation de fonctionnalité nuit à la modularité et oblige a passer par des accesseurs pour contourner le problème. On peut faire du très modulaire avec du procédural/impératif le risque est de faire du trop modulaire ou de structurer le code de façon exotique, ce qui au final peut nuire à la lisibilité. L'avantage de la POO est avant tout normative.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19function methode_de_remplissage_alternative(&$station, &$reservoir) { do { $station[reserve]– ; $reservoir[niveau]++ ; }while(($reservoir[niveau]<$reservoir[capacite]-10) && $station[reserve]>0) } $robert_service = nouvelle_station_service($station); $robert_service["remplir"] = 'methode_de_remplissage_alternative'; while($instances as $name=>$instance) { ... if($name=='monospace' && $instance['reservoir']['niveau']<10) $bernard_store['remplir']($instance); if($name=='voiture1' && $instance['reservoir']['niveau']<10) $robert_service['remplir']($instance); }
Je pense que tu sur-estimes le problème lié à l'encapsulation qui limiterait la modularité : on y est parfois confronté mais ça reste assez anecdotique. En revanche le fait de devoir passer par des closures pour masquer des informations, s'il s'agit bien d'encapsuler, me semble être autrement plus une source de complexité inutile.
A ce sujet l'encapsulation ne consiste pour moi qu'à empêcher le programmeur de faire des erreurs par inadvertance et lui communiquer clairement ce qu'il peut manipuler et comment. Il ne s'agit pas de dresser des fils de fer barbelés autour du code. Une approche consistant à simplement préfixer les membres privés d'un underscore est pour moi suffisante, même si moins commode à l'usage que les syntaxes dédiées à la visibilité.
A mes yeux les bénéfices de l’encapsulation sont bien plus nombreux que les nuisances. De plus, c’est un peu comme avec les Legos, si tu ressens le besoin de scier des briques pour que ta création ressemble à quelque chose, même si c’est tentant ça signifie surtout qu’il y a un souci d’analyse quelque part.
Ici, si j’encapsule les variables Capacite ou Quantite de mon réservoir afin d’éviter que celles-ci ne soient manipulables en dehors de la classe, ce n’est pas par sadisme mais plutôt pour éviter les potentiels effets de bords ; si je passe par une méthode publique pour remplir un réservoir, il y a fort à parier que ladite méthode fasse plus qu’une simple affectation de valeur, il y aura probablement une partie validation de données avant affectation, un prétraitement essentiel pour la fiabilité de l’application.
De même si je n’expose qu’une méthode sur la dizaine que renferme une classe, ce n’est pas pour castrer le développeur mais plus pour l’aiguiller. Si je lui avais laissé l’accès à tous les membres de la classe, le risque serait qu’il oublie de vider telle liste avant d’utiliser telle méthode, de déclencher tel évènement avant d’effectuer tel traitement...
L’encapsulation ne doit pas être vue comme un carcan mais, justement, comme un moyen d’organiser/structurer son code pour être manipulable en toute sécurité (surtout lorsqu’on bosse en équipe, chacun sur un pan métier différent par exemple).
On peut faire du structuré en procédural (encore heureux), mais pas autant qu’en OO de mon point de vue (du moins pas comme je l’entends ; structuré == organisé && sécurisé).
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager