...malheuresement c'est l'avenir
A+

1972 ? L'avenir ?

En fait, comme une bonne quantité de concepts et de matières, la programmation objet trouve ses sources dans la quantité incroyable (vu l'équipement de l'époque) de travail effectué dans les années 60-70. Genre les expression régulières, l'émail, etc... Les fondations de la programmation objet on étés posées par Smalltalk (rendu public en 80).

La programmation impérative existe de fait depuis plus longtemps, dés le début de l'informatique (années 40-50)

Et avant ça, on prenait un ciseau à froid, un maillet et une plaque de marbre, vous m'en graverez quatre copies et vous signez Ceasar

...malheuresement c'est l'avenir
A+

1972 ? L'avenir ?

En fait, comme une bonne quantité de concepts et de matières, la programmation objet trouve ses sources dans la quantité incroyable (vu l'équipement de l'époque) de travail effectué dans les années 60-70. Genre les expression régulières, l'émail, etc... Les fondations de la programmation objet on étés posées par Smalltalk (rendu public en 80).

La programmation impérative existe de fait depuis plus longtemps, dés le début de l'informatique (années 40-50)

J'ai cru comprendre que php sera de plus en plus orienté objet

PHP à l'origine était un langage purement procédural. Assez rapidement, le langage a évolué pour intégrer le concept d'objets et de classes. aujourd'hui, le modèle objet de PHP est autrement plus avancé et n'a plus grand chose à envier à d'autres langages orientés objet comme Java, C++ ou C# mais avec des approches parfois différentes, et éventuellement certaines implémentation manquantes, ou bien présentes alors qu'elles sont absentes des autres.

Je voudrais aussi te suggérer une réponse que j'ai faite à un autre sur la même question en matière d'évolution de ton codage du procédural vers la POO. Il y a une autre réponse que j'ai faite plus loin dans le même sujet qui complète la précédente.

Ok dans se cas je vais continuer en procédurale pour mieux comprendre le fonctionement d'un site e commerce, aprés j'éssayerai de refaire en poo pour le présenté dans le milieu profésionel
merci A+

De nombreuses librairies passent à l'objet oui, mais PHP en lui même reste sur une base procédurale.
Le jour où on ne pourra plus faire de chaîne de caractère sans instancier un objet String on en reparlera.

J'ai cru comprendre que php sera de plus en plus orienté objet

Ok merci pour vos réponses, j'ai du mal à changer mes habitude mais là malheuresement je vais devoir apprendre et surtout m'entrainer à faire de la poo avec php car malheuresement c'est l'avenir
A+

Ce n'est pas plus l'avenir que le procédural. ^^
Cela dépend de ce que tu as à développer. Certains programmes sont d'une difficulté à sauter par la fenêtre en POO alors qu'ils sont logiques en Procédural, et bien sûr on trouve des exemples inverses.

Ok merci pour vos réponses, j'ai du mal à changer mes habitude mais là malheuresement je vais devoir apprendre et surtout m'entrainer à faire de la poo avec php car malheuresement c'est l'avenir
A+

un language tel le c ou java

Juste pour digresser, mais C est impératif. Ce qui n'a pas empêche un certain J. Carmack d'employer du polymorphisme..

Je voix pas pourquoi c'est dure de passer du procédurale à l'objet puisque les classe sont coder en procédurale

Le paradigme même est complètement différent. L'objet permet un degré d'abstraction, d'indépendance du code qui rend tout travail par après bien plus facile (si correctement employé, sinon c'est pareil voir pire).

Imagine que dans un site e-commerce, tu dois gérer plusieurs types de cartes de crédit. Si chaque type de carte possède sa classe, tu peux utiliser ce qu'on appelle en conception objet un "factory", pour obtenir le bon type de classe sans que le reste de ton programme n'en soit conscient.

Genre, un bout de code, a titre d'exemple:

// $card_data comprend toutes les données envoyées par le formulaire de paiement.
// c'est "l'usine" qui s'occupe de choisir la bonne classe, nous on ne s'en occupe pas.

$card = card_factory::new_card($card_data);
if (!$card->is_valid())
  {
  // gestion d'erreur
  }

$card->invoice_amount('500')
     ->invoice_currency('euro');

if (!$card->payment_succes())
  {
  // gestion d'erreur
  }

Si une carte venait a changer (méthode de validation par ex.) ou si un nouveau type de carte venait à être supporté, ce bout de code resterait entièrement inchangé.
Pour ajouter un nouveau type de carte, il suffirait d'ajouter sa classe, et de le mentionner dans le fichier de configuration (que l'usine utilise pour détecter le type de carte). Aucune risque de modifier ou de devoir toucher un bout de code préexistant.
Activer ou désactiver un type de carte reviendrait à l'insérer ou pas dans le fichier de configuration, le reste du site étant tout à fait imperturbable quant à la diversité et le type de cartes supportées.


Et il n'y a pas que le procédural et l'objet (qui eux-même se subdivisent en familles). Il y a aussi le fonctionnel (Ha, essaie toujours de faire du traitement parallèle ou distribué sans perdre de cheveux avec du procédural), le déclaratif (Sql, Html...), par aspect, par contrainte, logique, etc.. C'est un peu le fouillis, puisqu'un paradigme n'empêche pas l'autre, mais en gros le meilleur c'est d'en connaître plusieurs, afin de pouvoir choisir, le cas échéant, le meilleur outil pour l'objectif a accomplir.

Je voix pas pourquoi c'est dure de passer du procédurale à l'objet puisque les classe sont coder en procédurale

C'est pas plus dur que de passer d'une voiture à boite de vitesse manuelle vers une voiture à boite automatique ... y a toujours un volant et 4 roues... par contre tu vas piler un certain nombre de fois avant de t'habituer au fait que la pédale de gauche ne sert pas à débrayer

Essai de faire appel a des équivalents des propriétés d'une classe. Des variables globales tu me dira oui mais qu'est ce qui empêche de les modifier par autres choses ?

Comment gère tu la persistance des donnée ? Une fois la fonction exécutée tu ne peux plus utiliser ce qu'il y a dedans or un objet est une représentation de quelque chose de "réel" et tu peux interférer dessus, tu passe ton objet d'un script a un autre.

Imagine un yeux de courses auto, tu utilise la méthode accélérer et la propriétés vitesse tu garde la vitesse de script en script sans problème pour faire la meme chose en procédurale tu utiliserais un tableau structuré qui n'est, au final un objet moins évolué.

Dans le cas d'un script e commerce, comme indiqué avant tu a, par exemple, un objet panier qui a un méthode ajoutarticle (suppressionarticle, modificationarticle etc etc).
Cette méthode prend en paramètre un objet article et la quantité.
A partir de la le caddie n'a pas besoin de savoir ciment est foutu l'article du moment qu'il peux accéder au prix et l'article se fou royalement de ce le caddie (ou qui que de soit) va faire du prix qu'on lui demande.
Au final tu a objet qui garde les données (la panier) tu le passe de page comme tu passerais un tableau en session mais tu devrais avoir des fonctions auquelles tu passée tableau en paramètre, tu devrais le gérer dans la gestion du formulaire etc etc.

Maintenant au vu de tes réponses je pense que tu est sur : l'objet c'est de la merde.
Si c'est le cas, comme tout le monde te l'a dit reste en procédural ça fonctionne aussi et dans le cas ou tu développe tous seul c'est pas un problème.
Sache simplement que la notion se retrouve dans tous ce qui développement que ce soit un language tel le c ou java mais aussi dans les sgbdr. Si l'on modélise les applications c'est pour avoir des chose "robuste" et maintenable a plusieurs sans se prendre la tête a savoir ce qu'à fait le mec d'a cote pour pouvoir pondre ses 3 lignes de code.

Tu peux aussi, sûrement. faire ton site oueb en assembleur mais cela sera Moins aisé

Essai aussi des language "full object" comme on dit, tel python ou java tu pourra voir la différence.

Mais en aucun cas ne te lance dans de l'objet si c'est pour faire comme tout le monde XD

@+

Je voix pas pourquoi c'est dure de passer du procédurale à l'objet puisque les classe sont coder en procédurale

C'est heureusement un peu plus que ça, mais comme cela a été dit plus haut, c'est surtout une question de projet

Concernant l'héritage, pour ton site e-commerce, et bien à moins que tes articles soient tous identiques (ex : uniquement des livres), les caractéristiques d'un lave vaisselle et d'un dvd ne seront pas les mêmes... et pourtant ce seront tous deux des articles que tu pourras ajouter à ton panier etc. donc l'héritage peut être intéressant.

L'encapsulation te permet de réunir dans une même entité les données et les moyens de les gérer, à savoir les attributs et les méthodes. Ainsi, au lieu d'une fonction générique demarrer() pouvant être utilisé n'importe comment, tu peux spécifier que la méthode demarrer() est liée uniquement aux objets de type "voiture", ce qui évitera que quelqu'un puisse essayer de démarrer une chaise ou un escalier. Une fois encore pour un site d'e-commerce, un dvd aura peut être une bande annonce (qui sera bien moins intéressante pour le lave vaisselle).

Enfin, le polymorphisme, te permet de redéfinir des méthodes liées à l'héritage. Ainsi, si l'on considère un objet Article et ses descendants DVD et LV possédant tous une méthode enregistrerEnBaseDeDonnees(), le système appellera la fonction enregistrerEnBaseDeDonnees() spécifique suivant que l'article est un DVD ou un lave vaisselle.

Un autre avantage de l'objet, c'est la ré-utilisabilité dans la mesure où ta classe va pouvoir servir à aux autres développeurs du projet. Pour des projets en équipe (ou tout simplement pour limiter les risques d'erreur), la visibilité des attributs et des méthodes peut aussi être très utile en obligeant celui qui utilises ton objet à passer là où toi tu l'autorises pour ne pas faire n'importe quoi (genre ne pas mettre la liste des acteurs dans le champ date de sortie)

Faut vraiment voir cela comme une autre façon de coder, avec ses avantages et ses inconvénients.. une fois encore tout dépend du projet (une cabane en brique c'est plus solide qu'une cabane en bois, mais ça tiendra jamais en haut d'un arbre...)

Un objet en réalité c'est rien d'autre qu'un regroupement de fonction et de variable qu'on apelle apelle d'une certaine maniére , le seul avantage d'aprés moi c'est l'héritage mais je voix pas vraiment l'utilité dans un site e commerce
puis pour la lisibilité je voix pas nomplus l'utilité car on peux faire encore mieux en fesant des commantaire et des inclusions de fichier pour chaque traitement d'information
merci pour vos réponse A+