Discussion :

[Anduriel]

Salut,
Je me demande souvent quelle est l'utilité des classes? En fait je vois des cas qui sautent aux yeux, comme les classes de connection SQL, mais sinon je ne vois pas trop...

En clair je voudrai savoir, dans quel cas utiliser les classes, alors qu'elles peuvent être généralement remplacées par des fonctions simples ?

Merci

[nako]

Salut, alors voici mon avis (qui n'engage que moi, bien entendu)
L'utilisation des classes est intéressante quand tu commences à développer une grosse application. C'est surtout que ça te permet de modéliser les choses correctement en faisant de l'objet.
Si de plus tu as un système de templates à ta disposition, alors là, c'est du régal, tu peux séparer ton application en architecture 3-tiers, et là, c'est vraiment très très propre.
a+

[Mr N.]

Principal avantage : maintenabilité !
Un code procédural est plus difficile à maintenir qu'un code OO.

Deuxième avantage : tests unitaires !
Chaque classe de ton application peut (doit) possèder son propre test. Du coup si tu modifies un truc dans ton appli et si bien sur tes tests sont bien faits, alors tu sais immédiatement si ta classe est impactée ou pas par ces changements... Quelques heures de debug gagnées à reporter sur le developpement. C'est plus difficile à faire avec un code procédural.

Les autres avantages tu les découvriras surement toi même

Mais bon il ne faut pas croire que passer à l'objet te produira ton code tout propre tout seul. Ca demande une certaine rigueur/méthodologie. Ce n'est pas parce qu'on code objet qu'on code proprement, et inversement ce n'est pas parce que notre code est procédural qu'il est sale.

[Fladnag]

je suis d'accord avec les avis précédent.

Une classe (bien développée) est un objet "fermé" (encapsulé) bien plus important que le niveau d'encapsulation des langages procéduraux qui se contentent du niveau "fonction".

Tu as donc une visibilité globale sur un composant de ton application sans avoir a te préoccuper des autres composants.

Tandis qu'avec un langage procédural, tu n'as que la fonction sous les yeux, et bien souvent tu dois comprendre l'integralité du code pour la resituer dans le contexte.

[loufoque]

L'OO permet surtout de séparer les implémentations et les interfaces.

[Mr N.]

L'OO permet surtout de séparer les implémentations et les interfaces.

Comment tu fais une interface en procédural ?
La question ici est l'avantage de OO par rapport au code procédural.

Il faudrait expliquer l'intéret, par ce que cet argument posé comme il l'est ne fait pas vraiment avancer le schmilblick, surtout pour un novice en Objet. (déjà que c'est pas forcément gagné pour ceux qui connaissent l'Objet...)

[Anduriel]

Merci à vous tous vos conseils me sont bien utiles

[sanosuke85]

* sent une goutte de sueur sur son front *

Bon alors voyons voir dans les lexiques... code procédural qu'est-ce que c'est ? code OO? hum... Bon on va trouver ^^ est plus difficile à maintenir qu'un code OO.

(NB : ce n'est pas une critique juste que j'ai lu ça m'intéressait ayant commencé à développer en objet mais je me demande si j'ai bien saisi l'intérêt primaire ^^ à revoir ^^)

[Mr N.]

Code procédural =>
code à l'ancienne, comme en cobol, pascal, php, c utilisation de simple function ou procédure...

Code OO =>
Code Orientée Objet (ou Object Oriented au choix) => utilisation des classes (PHP4, PHP5, C++, Java, Eiffel, ...)

[loufoque]

On peut très bien programmer orienté objet avec des fonctions.

[Mr N.]

Aller, crache le morceau ne nous fais pas languir Peux tu nous donner un exemple ?

[mathieu]

On peut très bien programmer orienté objet avec des fonctions.

exactement puisque les classes sont composées de fonctions et de variables.

Par contre cette discution devient philosophique, je ne pense pas que ça aide Anduriel. Pour les avantages de la POO, je propose toujours de lire l'article suivant, en entier pour ceux qui en ont le courage et sinon le chapitre qu'ils trouvent le plus intéressant pour les moins courageux
http://java.developpez.com/livres/pe...&page=0#00.002

[Mr N.]

exactement puisque les classes sont composées de fonctions et de variables.

J'appelle généralement les fonctions d'une classe méthodes...

Par contre cette discution devient philosophique...

+1
Tout ce qui peut être dit n'est pas propre à php !

[sanosuke85]

Merci à tous pour les réponses ^^ je n'ai plus qu'à aller me documenter ^^

[sekaijin]

programmer OO permet aussi de ce concentrer sur un objectif préci à la fois.

lorsque tu dois faire un certaint procéssus l'approche objet t'amenne à réfléchir sur ce que tu manipule. une fois que tu as identifé tes classes le processus que tu cherche à mettre en place te donne les "actions" à mener.

il te faut alors choisir quel obets est le plsu amême de remplir ce role.

lorsque tu à fais ce travail
tu ne te concentre pour chaque objet que sur l'action atomique en question.

les algos sont alors généralement très simple.

comme dit plus haut on peut très bien faire cela en procédural (GTK est fait ainsi)

l'usage des classes va te permetre de beneficier de mécanismes qui vont te faciliter la vie.

programer en objets permets aussi de se faciliter le travail pour développer par niveau d'abstraction.

par exempel lorsque tu gère le dialogue avec ton utilisateur les objets et les methods que tu dois utiliser sont toutes en rapport direct avec l'utilisateur.

trouver un client, ajouter un achat dans le caddie, etc.
il ne dois y avoir rien d'autre et peut importe comment sont définie le caddie l'achat ou le client

lorsque tu t'ocuppe de developper les algos interne de ces objets tu entre en contact avec les objets qui te permettent de garder les infos.
une base de donnée par exemple, un objet client qui cette fois est la représentation interne à ton appliue et non pas la présentation que tu enfait à l'utilisateur

etc.

A+JYT.

[Moloc'h]

Je me méfie de la programmation objet lorsqu'il s'agit de PHP. Beaucoup trop de "développeur PHP" font de l'objet pour l'objet, or il vaut mieux un site 100% procédural mais bien organisé qu'un site objet mal foutu.

Lorsque l'on veut faire un site en OO, il faut déjà réfléchir à une architecture global, plutôt que ce qui se fait dans la plupart du temps : "Ben ya ka transformer les fonctions en class et pis c'est tout". (dixit un de mes stagiaires).

[Mr N.]

200% d'accord.
Objet, c'est un état d'esprit, voire un mode de vie

[sanosuke85]

Moloch'

Je me fais l'avocat du diable ( ) car finalement pour moi, de ce que j'ai pu voir jusque là, je ne fais pas vraiment de différence entre créer une méthode pour un objet php et une fonction que tu peux appeler par un include() sur une page donnée...

Après en entrant dans les détails on aura le constructeur puis les méthodes qui en découlent, et je visualise que l'objet php est une "entité" à lui tout seul, facile à manipuler une fois fait, possibilité de passer ses paramètres via l'url encodé etc... Mais bon... Bien sur je précise que je ne suis pas un grand professionnel du php on se comprend et ceux qui le sont le verront par eux-même à travers mes phrases, mais je continue à chercher pour le moment le véritable intérêt des classes....

Bref tout ça pour dire : je suis d'accord avec toi mieux vaut programmer un bon site en procédural donc (j'apprends le langage ^^) qu'en OO qu'on ne comprend pas (ex : le forum que j'ai développé en utilisant des objets php et que finalement je me dis que j'aurais pu le faire en procédural ; après c'est comme ça qu'on apprend en se mettant des difficultés et des nouvelles évolutions ^^)...

voilà.

[the_jeck]

Le véritable intéret, par exemple : l'héritage

Où comment manipuler de la même façon de "ensemble" de données différentes mais ayant suffisament de caractéristiques communes...

exemple très simple :

on a une classe "figure_geometrique"
on a une classe "carre" qui hérite de "figure_geometrique" avec une methode "dessine" qui dessine le carré
on a une classe "cercle" qui hérite de figure_geometrique" avec une methode "dessine" qui dessine le cercle
etc...

on a un tableau avec plein des carrés et des cercles (comprendre des instances des classes "carre" et "cercle")

Pour dessiner l'ensemble du tableau, on a qu'a boucler sur les éléments du tableau et appeler pour chacune la methode "dessine" sans se soucier s'il s'agit d'un "carre", d'un "cercle", etc...

Et si plus tard on veux ajouter une classe "losange" qui hérite de "figure_geometrique" avec une méthode "dessine", on a rien à changer dans le traitement de notre tableau...

[Mr N.]

Le véritable intéret, par exemple : l'héritage..

+1 (j'avais oublié, mais c'est devenu tellement naturel)
Afin de paraître plus savant, préfèrons le terme Polymorphisme