Forum d'entraide PHPFrance

Bonjour

J'ai lu le chapitre d'introduction à la programmation orientée objet du livre "PHP 5 Avancé", qui était très intéressant. Cependant, je ne vois pas vraiment dans quels cas on peut utiliser la POO. A part créer des voitures ou des comptes en banque, quelle est son utilité?

Si vous pouvez m'éclairer un peu plus à ce sujet, je vous en serai reconaissant.

Merci

Salut,

en attendant d'autres avis, je vais essayer de répondre.
Une des utilités c'est de pouvoir réutiliser du code.
Exemple, tu fais une classe "Fraction". Une simple classe avec deux attributs "numérateur" et "dénominateur", et les méthodes de manipulation (ajout, soustraction, multiplication, simplification...)
Déjà, ça va te permettre de pouvoir ajouter 2 fractions simplement, sans avoir à refaire à chaque fois toutes les manips compliquées, qui seront déjà dans la classe.

Manipuler un objet et faire appel à des méthodes sera plus clair que de rebalancer tout le code à chaque fois (un peu comme avec les fonctions)

Et tu pourras réutiliser cette classe dans d'autres projets, facilement.
Dans le cas d'un langage compilé, tu pourrais aussi la mettre à disposition d'autres développeurs, qui pourraient utiliser les méthodes pour effectuer leurs opérations sur les fractions, sans voir le code qui est exécuté derrière. Bon pour le PHP c'est pas pareil

Voilà en gros les avantages, avis aux personnes qui voudraient compléter/corriger.

Moi ça m'interesserai de savoir si l'execution d'un script Objet serait plus rapide que dans une simple fonction?

Pas nécessairement, ça va jouer sur des nanosecondes. En revanche la portabilité du code est beaucoup plus intéressante. Un autre avantage d'une classe objet, c'est que tu n'as pas besoin, comme te l'a dit ouckileou, de ré-écrire le code, mais j,ajouterais que pour une autre application, tu n'aurais même pas besoin de ré-écrire une classe pour l'adapter : si ton code est suffisament générique, tu n'as éventuellement besoin que d'écrire une classe héritée qui va faire des surcharges de méthodes ou de propriétés qui s'adapteront parfaitement à ta nouvelle application.

L'un n'est pas nécessairement mieux que l'autre.

Un code procédural basé sur des fonctions bien organisées vaut mieux que des classes mal faites. On peut également se constituer des bibilothèques de fonctions à inclure et les organiser de manière logique.

Ceci dit, une bonne organisation de classes est plus facile à gérer si on a une bonne discipline de programmation. La notion d'héritage, entre autre, facilite sensiblement l'organisation de ce code. Un bon exemple est la bibliothèque PEAR qui, contairement à ce qu'on en dit, n'est pas une usine à gaz. On y prend que ce qui est nécessaire. Elle est bien structurée car basée sur une bonne organisation de classes et des conventions de codage bien définies.

Tu as des notions intéressantes ICI

Je pense qu'il est difficile de juger dans le cas de php. Personellement, je n'ai jamais vraiment utilisé de POO en php, si ce n'est pour essayer.
Mais dans le cas de langage tel que Java, c'est indispensable, ne serait que pour des questions de gestion de projet: sur un programme un tant soit peu conséquent, une programmation séquentielle est tout bonnement impossible.
En très résumé:
L'objet permet justement une découpe logique et beaucoup plus proche de la réalité du problême à traiter. Un exemple récurent très souvent utiliser est celui d'une cuisine: on doit éplucher différents légumes, si c'est la classe cuisinier qui doit savoir comment éplucher chaques légumes différents, àa risque d'être ardu, par contre si chaque légume sait comment s'éplucher, le cuistot doit juste savoir comment le lui demander, par une interface convenue.
En gros, on demande on service à un objet, on sait ce qu'il doit nous fournir comme "service" mais on ne s'interesse pas sur comment il va le faire, ou comment seront stockées les données.
Ce qui très très pratique dans le cadre d'un projet d'équipe, on se met d'accord sur les responsabilité de chaques classes, et ensuite au dévellopeur de faire leur cuisine interne pour arriver à remplir leur "contrat"

Mais alors si l'avantage principal est la portabilité d'un projet à l'autre je ne vois pas pourquoi je ne ferais pas des classes avec des fonctions.

Mon chef de projet me demande que l'orsque on me donne le nom d'un restaurant je sois capable de sortir les produits dans un tableau.

De cette mannière:

Fonction 2 (resto, entrée) // Requete SQL
Fonction 3 (resto, plats) // Requete SQL
Fonction 1 (resto) // Constructrice return array(Fonction 2, Fonction 3)

Dans ce cas j'ai un code bien organisé (chaque fonction à sa fonction (logique ) et j'ai une entrée principale et une sortie principale.

Mon chef est content et j'ai une prime même sans les classes.

Cela dit j'aime bien les classes moi, je trouve que ça fait plus professionel et les débutants ne comprennent rien

Au lieu d'utiliser des fonctions assez complexes ou d'avoir un code redondant, développer des classes pour réutiliser ses objets put être beaucoup plus facile au niveau du développement par la suite!
ça sert à simplifier la vie tout simplement!