Bonjour à tous

Cette discussion fait suite au topic "Apprendre la POO doucement..." lancé par Supercanard, que je remercie pour son indulgence, puisque je me suis permis de poser quelques questions personnelles à propos de la POO dans son fil de discussion...

Du coup, pour ne pas trop gêner son échange, et pour séparer un peu les sujets afin que chacun puisse les suivre au mieux, j'ai décidé de lancer cette autre discussion à propos des mystères de la POO

Je remercie ici aussi à Cyrano et à Ryle pour leurs réponses déjà très instructives sur l'autre topic... en espérant qu'ils voudront bien venir par ici me prodiguer d'autres conseils et avis...

...

Alors, poursuivant avec mes interrogations sur la pertinence de développer en POO, je tente de me faire une idée, la plus claire possible, du principe et des concepts attachés à la POO, afin de pouvoir choisir, un jours peut-être en toute connaissance de cause, entre la POO et le procédural...

Pour l'instant, à vrai dire, j'ai un peu de mal à percevoir tous les avantages que Ryle a si bien expliqué dans son message, même si je comprends le but, leur application effective me semble encore bien confuse...

Pour illustrer l'ampleur de mon égarement dans le monde impitoyable du développement, voici deux codes qui produisent exactement le même résultat (à quelques détails près), et qui ont un fonctionnement aussi simple l'un que l'autre, seulement, leur approche est très différente, la première utilise la fameuse méthode POO et la seconde se contente d'une méthode procédurale des plus classiques...

...

Il s'agit donc, tout bêtement, d'imaginer un simple carnet de contacts (faut bien commencer avec des choses simples au début... non ? ) :

Méthode POO

<?php
// Class 'contact'
class contact {
	var $nom;
	var $prenom;
	var $telephone;
	
	function contact($leNom, $lePrenom, $leTelephone) {
	// Constructeur avec valeurs par defaut pour les proprietes
		list ($this->nom, $this->prenom, $this->telephone) = array($leNom, $lePrenom, $leTelephone);
	}
	
	function lire() {
	// Retourne les infos du contact sur une ligne
		return $this->prenom.' '.$this->nom.' - Tél. : '.$this->telephone;
	}
	
	function modifier($variable, $valeur) {
	// Modifie une info du contact
		if (isset($this->$variable)) { $this->$variable = $valeur; }
	}
}

// Creation d'un nouveau contact
// Instance '$claude' de la class 'contact' avec des valeurs passees au constructeur
$claude = new contact('François', 'Claude', 'Il pleur...');
echo $claude->lire(); // Affichage : Claude François - Tél. : Il pleur...

echo "\n".'<br /><br />'."\n";

// Modification des certaines infos
$claude->modifier('nom', 'Nougaro');
$claude->modifier('telephone', '');
echo $claude->lire(); // Affichage : Claude Nougaro - Tél. : 
?>

Méthode Procédurale

<?php
// Fonctions de travail
function contact($nom, $prenom, $telephone) {
// Retourne une nouvelle liste contact
	return array('nom'=>$nom, 'prenom'=>$prenom, 'telephone'=>$telephone);
}

function lire($contact) {
// Retourne les infos du contact sur une ligne
	return $contact['prenom'].' '.$contact['nom'].' - Tél. : '.$contact['telephone'];
}

function modifier($contact, $variable, $valeur) {
// Modifie une info du contact et retourne la liste mise a jour
	if (isset($contact[$variable])) { $contact[$variable] = $valeur; }
	return $contact;
}

// Creation d'un nouveau contact
$claude = contact('Françaois', 'Claude', 'Il pleur...');
echo lire($claude);  // Affichage : Claude François - Tél. : Il pleur... 

echo "\n".'<br /><br />'."\n";

// Modification des certaines infos
$claude = modifier($claude, 'nom', 'Nougaro');
$claude = modifier($claude, 'telephone', '');
echo lire($claude); // Affichage : Claude Nougaro - Tél. : 
?>

...

Bon, je ne sais pas vous, mais moi j'ai encore du mal à percevoir les avantages de la méthode POO sur une manipulation de ce type...

Alors, ce qui serait sympa et fort instructif, et là je m'adresses aux Pros de la POO, c'est que, à partir de ce simple exemple, on arriver à illustrer le plus clairement possible ce qu'apporterai la POO par rapport au procédural si on voulait améliorer ou étoffer ces codes... vous voyez ?

Bref, s'il y a des courageux volontaires pour éclairer un peu mon obscurantisme programmationel , ce serait vraiment génial

Merci encore pour vos lumières

Je suis pas un spécialiste de la POO, 20 à 30% de mon code est développé de cette façon. Mais bon imagine que le code que tu viens de faire puisse servir dans d'autres scripts.
Le premier côté pratique est que tout que ce qui sert à ton script est intégré à l'intérieur d'une classe; çe sert à ranger les fonctions nécessaires à ton script à l'intérieur d'un même objet.
Autre remarque c'est plus rapide pour avoir accès aux variables que tu as définies dans ta classe. Dans ton exemple, une fois la classe instanciée, tu peux avoir accès directement au téléphone en faisant $claude->$this->telephone.
Par ailleurs ces mêmes variables peuvent être utilisées par toutes les fonctions de la classe, ce qui peut te permettre d'avoir moins d'arguments à passer dans tes fonctions. Pour faire l'équivalent en procédural il faudrait passer par des variables globales avec tous les pb de sécurité inhérentes à celles-ci.

Les pro de la POO t'en diront certainement plus. Moi je vois surtout le côté pratique. Cela dit avec ta manière de programmer en procédural (recours aux fonctions qui n'exécutent qu'un traitement spécifique), tu ne devrais pas avoir de difficulté à passer au mode objet.

EDIT : cela dit je me méfie un peu des conseils à suivre "aveuglément". Dans le mode objet on préconise assez souvent d'utiliser des fonctions qui ne font qu'un traitement spécifique.
Si l'on prend l'exemple d'un tableau sur lequel on doit effectuer 4 modifications successives, la "philosophie" objet voudrait que l'on fasse ces quatre modifications dans quatre fonctions différentes, c'est à dire passer le tableau en revue quatre fois. Si le tableau ne comporte que quelques dizaines d'éléments, on ne verra pas la différence, mais pour plusieurs dizaines de milliers d'éléments la différence sera significative.
Mon exemple est un peu caricatural, mais c'est juste pour souligner qu'en mode objet comme ailleurs, les conseils que l'on donnent sont souvent dépendants du contexte dans lequel on les donne.

Bonjour AB et merci beaucoup d'avoir partagé ton avis !

Le premier côté pratique est que tout que ce qui sert à ton script est intégré à l'intérieur d'une classe; çe sert à ranger les fonctions nécessaires à ton script à l'intérieur d'un même objet.

Oui, c'est vrai que le fait d'encapsuler un ensemble logique (je n'ose dire cohérent) de variables et des fonctions, est plutôt sympa, cela permet d'avoir un code plus clairement structuré je suppose...

La question que je me pose maintenant à ce propos est la suivante :

- Je crée une classe avec son lot de variables et fonctions, mais si jamais j'ai besoin d'utiliser une des fonctions de la classe pour faire un traitement à l'extérieur de l'objet, puis-je le faire ou dois-je avoir une fonction équivalente indépendante de toute classe ?

- Et son corollaire, si jamais j'ai besoin d'utiliser une fonction indépendante mais à l'intérieur d'un objet, puis-je avoir accès ou dois-je encapsuler une fonction équivalente dans la classe avant de créer l'objet ?

Bref, l'interaction entre les fonctions de l'objet et du script est-elle aisée ou faut-il multiplier les fonctions similaires, les unes pour les objets et les autres pour le script ?

Désolé si ces questions paraissent bêtes ou absurdes, elles démontrent tout simplement ma parfaite méconnaissance du sujet.

Autre remarque c'est plus rapide pour avoir accès aux variables que tu as définies dans ta classe. Dans ton exemple, une fois la classe instanciée, tu peux avoir accès directement au téléphone en faisant $claude->$this->telephone.

En effet, j'ai testé et cela fonctionne plutôt bien (la syntaxe $claude->telephone seulement fonctionne chez-moi, mais c'est peut-être du à ma version de Php)...

Par ailleurs ces mêmes variables peuvent être utilisées par toutes les fonctions de la classe, ce qui peut te permettre d'avoir moins d'arguments à passer dans tes fonctions. Pour faire l'équivalent en procédural il faudrait passer par des variables globales avec tous les pb de sécurité inhérentes à celles-ci.

Ha oui, ça c'est une remarque très intéressante, cela veut dire que, contrairement aux fonctions indépendantes, qui ont besoin qu'on déclare les variables du contexte général par le mot "global" pour être utilisables en local, celles présentes dans une classe ont un accès directe à toutes les variables du contexte (propriétés devrais-je plutôt dire dans ce cas) sans un notation spécifique... intéressant en effet !

Les pro de la POO t'en diront certainement plus. Moi je vois surtout le côté pratique. Cela dit avec ta manière de programmer en procédural (recours aux fonctions qui n'exécutent qu'un traitement spécifique), tu ne devrais pas avoir de difficulté à passer au mode objet.

J'ai en effet pris l'habitude, peu à peu, à simplifier mes fonctions pour qu'elles n'assurent que des traitements relativement basiques, mais tous mes projets ne sont pas codés ainsi, loin de là, disons que c'est une pratique que je tente de mettre en place depuis quelques mois seulement...

EDIT : cela dit je me méfie un peu des conseils à suivre "aveuglément". Dans le mode objet on préconise assez souvent d'utiliser des fonctions qui ne font qu'un traitement spécifique.
Si l'on prend l'exemple d'un tableau sur lequel on doit effectuer 4 modifications successives, la "philosophie" objet voudrait que l'on fasse ces quatre modifications dans quatre fonctions différentes, c'est à dire passer le tableau en revue quatre fois. Si le tableau ne comporte que quelques dizaines d'éléments, on ne verra pas la différence, mais pour plusieurs dizaines de milliers d'éléments la différence sera significative.
Mon exemple est un peu caricatural, mais c'est juste pour souligner qu'en mode objet comme ailleurs, les conseils que l'on donnent sont souvent dépendants du contexte dans lequel on les donne.

N'ai crainte, je suis toujours très attentif aux conseils des autres, surtout lorsque j'en fais la demande et d'autant plus qu'ils émanent de personnes plus expérimentées que moi, mais, sans les mettre nécessairement en doute, j'aime bien tout de même me forger ma propre opinion en testant de mon côté les solutions qu'on me confie, par pur besoin de comprendre...


Enfin, je me rends compte que le développement à la mode POO garde encore bon nombre de mystères pour moi, peut-être qu'en m'y mettant un jour, sérieusement, et en réalisant un projet entier avec cette méthode de programmation, peut-être (j'insiste), j'arriverai un jour à comprendre un peu mieux tout l'intérêt de la chose... pour le moment, hélas, cela reste encore assez flou dans mon esprit...

Merci encore AB pour ton message

Dans leur fonctionnement, il faut bien avouer que tout ce que l'on fait en objet peut être fait de manière procédural (c'était d'ailleurs le cas jusqu'à ce qu'on introduise la notion d'objet ). L'encapsulation équivaut à une librairie de fonctions, la visibilité se retrouve dans la nomenclature hongroise, le polymorphisme dans le renommage des fonctions, etc. Au final la POO n'a rien inventé

Maintenant essayons de trouver quelques exemples illustrant l'intérêt de la première méthode

- Première idée qui me vient (parce qu'elle manque à ton code), spécifiée comme privée les attribut de la classe. L'intérêt, c'est que celui qui va utiliser ta classe ne pourras pas faire un $claude->telephone = 'xxx' pour modifier le téléphone où tout autre champ et sera obligé d'utiliser la méthode modifier(). En procédural, il a le choix et peux accéder à $claude['telephone'] pour le modifier.
L'intérêt, c'est l'intégrité des données. Supposons que je crée dans mon objet une méthode setTéléphone() qui va faire une batterie de test sur le numéro pour s'assurer de son format avant de renseigner l'attribut, je peux être certain que le numéro aura toujours le format que j'attends (puisque ma méthode le formatera ou renverra une erreur en cas de problème). En procédural, même si tu écris une fonction équivalente, tu n'as aucune garanti qu'elle soit utilisé et ne pourras jamais être certain de la façon dont le champ a été renseigné, et donc de son format.

Accesoirement, tu te simplifies également la vie au moment du codage, puisqu'un bon IDE te proposera les méthodes de l'objet auxquelles tu as le droit d'accéder, ce qui sera toujours plus agréable que de devoir retenir la liste des index d'un tableau pour savoir lequel modifier

- Deuxième idée, cocnernant le polymorphisme, supposons qu'à côté des contact tu ais besoin de gérer .. chais pas moi... des signets ou autre... il te faudra alors également des méthodes lire() ou modifier() ... en POO c'est simple, elles seront dans l'objet Signet, mais en procédural, il va te falloir renommer l'une des deux puisque tu ne peux pas avoir deux fonctions avec le même nom. Pourtant elles font bien la même chose et si tu l'appelles modifierFavori(), il te faudrait pour être cohérent, revenir sur ton code précédent (qui marchait pourtant bien depuis 3 ans) pour changer ce modifier en modifierContact() ou te galérer à chaque fois à te rappeller que celui là spécifiquement est le seul qui s'appelle "modifier" tout court pour d'obscurs raisons historiques...

Bon ça en fait déjà 2 à froid, je compléterais s'il m'en vient d'autres (et y en aura, j'ai pas abordé l'héritage ), mais ça peut déjà te présenter quelques avantages, même si une fois encore, tout peut être fait de manière procédurale

En effet, j'ai testé et cela fonctionne plutôt bien (la syntaxe $claude->telephone seulement fonctionne chez-moi, mais c'est peut-être du à ma version de Php)...

Nope, pas la version de php qui est en cause, juste une étourderie C'est effectivement $claude->telephone la bonne syntaxe pour accéder à un attribut d'une instance. Le $this->telephone fait référence à l'instance lorsque tu trouves à l'intérieur de la classe

- Je crée une classe avec son lot de variables et fonctions, mais si jamais j'ai besoin d'utiliser une des fonctions de la classe pour faire un traitement à l'extérieur de l'objet, puis-je le faire ou dois-je avoir une fonction équivalente indépendante de toute classe ?

Tu pourrais assez simplement instancié un objet et appellé une de ces méthodes en lui passant les arguments dont tu as besoin en paramètre. L'intérêt est effectivement dans ce cas de regouper les fonctions qui concernent le même domaine dans un même objet.

Il est toutefois également possible d'utiliser le mot clé "static" qui va en fait indiquer qu'une méthode (ou un attribut) ne nécessite pas l'instanciation d'un objet spécifique, mais peut être utilisée directement depuis la classe. En effet, si tu n'as pas besoin d'accéder aux attributs ou à d'autres méthodes non statiques de ta classe, tu peux utiliser la syntaxe Classe::methode() (au lieu de instance->methode()) pour appeller une méthode de ta classe comme n'importe quelle autre fonction php

- Et son corollaire, si jamais j'ai besoin d'utiliser une fonction indépendante mais à l'intérieur d'un objet, puis-je avoir accès ou dois-je encapsuler une fonction équivalente dans la classe avant de créer l'objet ?

Toutes tes fonctions peuvent être appellée sans restriction à l'intérieur d'un objet
Concernant les méthodes membres d'autres classes, cela dépendra de leur visibilité (ces histoires de public, protected, private qui permet d'y avoir droit ou pas )

La question que je me pose maintenant à ce propos est la suivante :

- Je crée une classe avec son lot de variables et fonctions, mais si jamais j'ai besoin d'utiliser une des fonctions de la classe pour faire un traitement à l'extérieur de l'objet, puis-je le faire ou dois-je avoir une fonction équivalente indépendante de toute classe ?

- Et son corollaire, si jamais j'ai besoin d'utiliser une fonction indépendante mais à l'intérieur d'un objet, puis-je avoir accès ou dois-je encapsuler une fonction équivalente dans la classe avant de créer l'objet ?

Bref, l'interaction entre les fonctions de l'objet et du script est-elle aisée ou faut-il multiplier les fonctions similaires, les unes pour les objets et les autres pour le script ?

De l'extérieur, tu peux avoir accès à une fonction "public" ou "static" d'une classe en faisant $maclasse::mafonction();

Maintenant concernant le fait de multiplier des fonctions identiques à l'intérieur de chaque classe qui seront éventuellement utilisées conjointement, c'est à toi de voir suivant le contexte et la fréquence du "conjointement".
Comme l'a dit Ryle, le fonctionnement en POO permet d'avoir deux fonctions portant le même nom dans des classes différentes, donc ça ne gêne pas et permet une meilleure autonomie de ta classe.
D'un autre côté, si tu fais une classe qui a systématiquement besoin d'une connexion à une bdd, il est probable que d'autres composants du script (extérieurs à la classe) en aient besoin également. Intégrer la connexion à l'intérieur de chaque classe serait redondant, d'autant plus que si tu changes ta méthode de connexion il faudrait ensuite la changer à l'intérieur de chaque classe.
Donc c'est à toi de voir suivant les cas

Sinon je me permet de te conseiller de ne pas attendre d'avoir "toutes" les connaissances pour faire une brique de projet en POO.
Les tutos et les bons exemples sont indispensables mais c'est par la pratique que tu te poseras les bonnes questions et que tu trouveras les bonnes réponses. ça met du temps et pour moi tout vouloir ingurgiter d'un coup n'est pas la meilleure méthode. Je préfère en faire un peu, puis laisser reposer, et voir à l'usage ce qu'il conviendrait d'améliorer, et par la même occasion, ce qu'il est inutile de tenter d'essayer d'améliorer...
Donc tu peux commencer déjà par les briques qui reviennent les plus souvent dans tes projets et la mise en route de la réflexion POO sera initiée, sans pour autant que le projet soit tout en POO.

Maintenant s'il te faut être absolument être un cador en quelques semaines, il va te falloir une sacré immersion

EDIT : bon j'étais entrain de manger pendant que je répondais, du coup Ryle avait répondu à à tes questions entre temps...

Hey ,

Ryle a très bien illustré l'avantage de la POO : l'intégrité des données.
En utilisant le mot clé static, tu peux retrouver les données qui sont dans les attributs (variables ou paramètres de l'objet) n'importe où dans ton code. Avec une méthode fonctionnelle (et pas procédurale), tu ne peux pas stocker des données quelques part pour les réutiliser. Si tu veux que des données se baladent d'une fonction à une autre, tu es obligé de passer par des variables intermédiaires ou d'imbriquer tes fonctions. Dans le cadre de la POO, tes données sont dans les attributs, et les méthodes peuvent piocher dedans. Pas besoin de se prendre la tête .

Attention au vocabulaire aussi. En programmation fonctionnelle, on parle de fonction. En programmation orientée objet, on parle de méthode (en gros, ce sont des fonctions dans l'objet). Mais le fait de dire méthode ou fonction nous permet de savoir exactement de quoi on parle tout de suite.

L'exemple de Ryle sur le polymorphisme n'est peut-être pas très clair. Mais je voulais te donner une idée avec l'héritage (relation entre les classes).
Il faut voir les classes comme des boîtes, ou des groupes. On donne des données à la boîte. La boîte traite les données, et les stocke. Ensuite, on interroge la boîte pour obtenir différent résultat. Seulement, une boîte seule n'est pas forcément utile.
Dans ton cas d'un carnet d'adresse : imagine que l'on veuille étendre les capacités de ce carnet d'adresse pour l'incorporer dans un outil de messagerie. Ton carnet d'adresse ne fait pour l'instant que stocker, et modifier les données. Mais pour un programme de messagerie, il nous faudrait pouvoir faire une recherche sur ces données, et même un tri par exemple. Par défaut, ces actions ne sont pas possibles. Alors on va créer une autre classe qui va étendre la première pour lui ajouter des fonctionnalités.
Tu as vu qu'il y a plusieurs modes d'accès pour les données : public (accessible depuis partout, même depuis l'extérieur de l'objet), et privé (seulement pour l'objet). Mais il y en a un troisième : protégé. C'est à dire que l'objet pourra y accéder, mais également les membres de sa famille (c'est à dire les classes qui l'étendent). On a donc des données communes/partagées entre différents objets en relation.

Ici tu vois que la POO te permet d'avoir des traitements atomisés (une méthode par traitement grosso modo) et aussi de grouper des traitements (en classe). Ainsi, ton code est mieux structuré.
Si tu as besoin d'ajouter des fonctionnalités à une classe, tu peux soit modifier le code directement dans le cas où ça concerne exactement la classe, mais si on veut ajouter des fonctionnalités un peu différent mais toujours en rapport, alors on va créer une nouvelle classe et la mettre en relation avec la première.

Les objets peuvent se mettre en relation via l'héritage, mais il existe beaucoup de possibilité, comme l'association, qui consiste à imbriquer des objets entre eux. Les objets utilisent des objets pour manipuler des données très particulière. Par exemple : l'objet Mail, pour envoyer le mail, va utiliser l'objet SMTP pour gérer les envoies. Mais il peut aussi utiliser l'objet PHPMail, etc. Impossible de faire ça avec du fonctionnel sauf si on écrit tous les cas un par un.
En objet, tu as une grande dynamique avec les objets. Tu as ce qu'on appelle l'emboîtement (ou l'imbrication) et c'est très puissant.

Après, chaque langage a ses spécificités. Tu voulais connaître les avantages de la POO, et pas le fonctionnement de la POO, je n'approfondis donc pas. Mais sache que C++ permet un héritage multiple, c'est encore une conception très différent. Il faut donc explorer .

Bonjour à tous

Et bein, moi qui pensais n'avoir pas beaucoup de réponses, je suis agréablement surpris et, surtout, très impressionné par vos messages, précis, clairs et complets... j'ai pas mal de relecture et du pain sur la planche pour essayer de tout comprendre...

Merci à tous en tout cas à tous pour toutes ces explications !

Bon, je ne vais pas répondre individuellement à chacun, j'y passerais la nuit ... enfin, vu l'heure qui est, il n'en reste plus grand chose de la nuit, mais bon, je n'ai pas encore fait dodo et mes yeux commencent à se fermer tout seuls, je vais donc être bref dans cette réponse ...

Alors, en gros, je pense avoir saisi relativement bien, en théorie pour l'instant du moins, les arguments que vous avancez concernant les avantages et particularités de la POO, même si certaines notions méritent encore que je m'y penche de plus près (le polymorphisme par exemple)...

Seulement, et vous aller me trouver un peu lourd, pour ne pas dire carrément chiant, autant j'arrive à comprendre l'utilité de la POO lorsqu'il s'agit d'objets comme des véhicules et des voitures ou autres motos, autant j'ai du mal à transposer tout ça concrètement dans mon univers de développement...

Je m'explique :

Jusqu'à présent, dans mon modeste parcours de développeur (juste du dimanche), je n'ai fait que des petits utilitaires pour ajouter des fonctionnalités à mes réalisations web, qui ne sont pas nombreuses je dois avouer, et quelques autres projets mineurs dont la plupart sont encore en cours de développement...

Donc, le coeur du problème, en ce qui me concerne, c'est que je ne sais absolument pas comment juger de la nécessité ou de la pertinence de réaliser un projet en POO ou en procédural, autrement dit, je n'ai pas suffisamment d'éléments, et une vision assez précise, pour arriver à déterminer, au début d'un projet, quel méthode de développement serait la plus approprié au projet en question...

Bref, pour l'instant la question la plus basique et fondamentale pour moi, à propos de la POO, c'est :

- Quand est-ce utile ou intéressant de développer en POO et quand ça ne l'est pas ?

Si vous aviez des exemples de réalisations qui profitent avantageusement de la POO et d'autres qui s'en passent très bien, ceci pourrait éventuellement m'aider à y voir un peu plus clair...

Après, une fois cette question évacuée (satisfaite j'espère ), j'y reviendrais plus volontiers à traiter par la pratique avec vous des différents aspects de la POO, car, pour répondre un peu à AB, je n'attends pas de tout savoir avant de mettre les mains dans la pâte (ce serait de toutes manières impossible vu la somme de connaissances à acquérir), puisque j'ai déjà fait quelques petits tests pour essayer de comprendre un peu le fonctionnement de base de tout ça...

Enfin... comme vous pouvez le constater, j'essaie de rester encore assez mesuré dans mon approche de la POO, histoire de savoir si tout ceci a finalement une quelconque utilité dans mes développements actuels...

Un très grand merci encore à tous pour m'aider à y voir plus clair !

à+

En fait la poo s'impose assez naturellement dès que tu commences à travailler avec d'autres personnes qui vont devoir utiliser tes scripts (ou lorsque tu devras utiliser les leurs). Pas de risque que vous soyez deux à avoir une fonction modifier(), pas de risque qu'un jour quelqu'un estime qu'il va aller plus vite a renseigner ton tableau directement parce qu'il n'a pas vu ta fonction (qui aurait fait tout les tests avant de changer la valeur), plus facile également de standardiser des choses, etc.

Maintenant, c'est également une question de contexte. Si tu dois développer en C, tu n'auras que du procédural. Si en revanche tu dois développer en Java, il n'y aura que de l'objet. PHP reste un langage procédural mais te permet d'introduire des classes.. a toi de voir ensuite où et quand tu pourrais en avoir l'usage

Personnnellement j'utilise encore une librairie de fonctions pour gérer mes connexions à la base de données, bien que cela pourrait tout aussi bien se faire à l'aide d'une classe (ca viendra peut être un jour). En revanche pour chacune de mes tables en base j'ai créé un objet qui lui est associé. Je n'ai ainsi aucune requête sql qui traine dans mes pages, elles sont toutes dans leurs objets respectifs et je n'ai ainsi pas à les chercher.
Une méthode load() me permet de charger un enregistrement spécifique de la table en lui passant son id, elle renseigne mes attributs et je peux ensuite manipuler mon enregistrement à ma guise. Des méthodes insert(), update() et delete() vont exécuter les requêtes correspondantes pour insérer l'objet manipulé en base, ou le mettre à jour ou le supprimer. L'avantage, c'est que je ne me pose aucune question, je fais une modif sur un objet quel qu'il soit, j'appelle update() et je sais que la modif est enregistrée en base, sans avoir à repréciser l'id ou la requête ou les autres valeurs

Voilà en gros ma façon d'utiliser les objets en php... y en a d'autres, peut être de meilleures, sans doute des frameworks qui imposent aussi une façon de travailler, mais celle-ci me convient bien (c'est également une question d'habitude), donc pour le moment je reste dessus et mes collègues en sont également satisfait, ça nous simplifie beaucoup les échanges et la vie

Au final, c'est bien de savoir que ca existe, de comprendre comment ça fonctionne, mais ça n'a, selon moi, rien d'une obligation pour un site perso où des choses simlpes comme un tableau. Ca devient interessant dès que tu commences à manipuler une structure plus complèxe

Ryle a encore raison. La POO est une philosophie de travail.
Pour ma part, j'aime beaucoup l'objet : c'est une méthode et une façon de penser que j'apprécie beaucoup. Si cela te convient, c'est parfait, mais peut-être que tu vas préférer le programmation fonctionnelle, procédurale, par prototype, etc. Il faut trouver la programmation qui est adapté à ton besoin et qui répond le plus à ta demande. Il ne faut pas faire de la POO pour en faire, ou parce que c'est à la mode. Il faut en faire si tu en as besoin .

Re bonjour

Au final, c'est bien de savoir que ca existe, de comprendre comment ça fonctionne, mais ça n'a, selon moi, rien d'une obligation pour un site perso où des choses simlpes comme un tableau. Ca devient interessant dès que tu commences à manipuler une structure plus complèxe

Voilà ce que j'appelle une réponse pleine de bon sens !

Pour l'instant, dans le cadre de mes projets (je trouve soudain ce mot, "projet", bien sur-dimensionné pour ce que je fait en réalité, mais bon... admétons ), j'arrive, tant bien que mal, à faire ce que je souhaite, pas forcément de la meilleur des façons, parfois même de manière assez brouillonne, mais je m'en sort plutôt pas trop mal en général... et, lorsque je bloque, un petit coup de PhpFrance et c'est reparti pour un tour...

Pour l'instant, comme je ne sais pas faire autrement, je vais continuer avec ma manière de coder, mais je vais quand-même tenter l'aventure, sur un prochain projet, de le réaliser entièrement avec la méthode Objet, c'est alors que je pourrais me faire une idée un peu plus précise si cette méthode de développement pourrait correspondre a mes besoins ou pas...

Enfin, comme tu dis Ryle, la POO ce n'est pas une obligation, je peux donc continuer mes petits bricolages maison sans trop culpabiliser d'être un ignare en la matière... ... en tout cas, en attendant de faire mes premières armes dans l'étrange univers des objets...

Ryle a encore raison. La POO est une philosophie de travail.
Pour ma part, j'aime beaucoup l'objet : c'est une méthode et une façon de penser que j'apprécie beaucoup. Si cela te convient, c'est parfait, mais peut-être que tu vas préférer le programmation fonctionnelle, procédurale, par prototype, etc.

Ha, tiens, voilà des notions qui me sont inconnues, quelle différence existe entre ces autres méthodes de programmation : fonctionnelle, procédurale, par prototype, etc. ???

Aurait-il une page web qui expliquerait ces différentes méthodes de programmation ?

Il faut trouver la programmation qui est adapté à ton besoin et qui répond le plus à ta demande. Il ne faut pas faire de la POO pour en faire, ou parce que c'est à la mode. Il faut en faire si tu en as besoin .

Voilà, tu as visé juste !

Je ne souhaite pas m'accommoder d'une mode ou tendance si cela ne correspond pas à ce que j'ai réellement besoin, mais, d'un autre côté, si j'ignore tout de ce qui existe, je serais de toutes manières incapable de savoir si j'ai vraiment besoin de telle ou telle technique...

Bref, pour l'instant je tente de recueillir des d'infos et avis autour de ce sujet, histoire d'en dessiner un peu les contours et de me faire une petite idée de ce que c'est la POO et dans quel cadre cela pourrait m'être utile un jour...

Toutes vos réponses sont d'ailleurs une mine d'information et vos avis éclairés une solide base de réflexion... il ne me reste plus qu'à tester de mon côté sur quelque chose de concret pour savoir si finalement la POO peut m'apporter quelque chose ou pas dans mes réalisations...

De toutes manières, lorsque je serais plongé dans les "classes" jusqu'au cou, ne vous étonnez donc pas de me voir revenir par ici pour vous tanner avec mes questions à deux balles... maintenant que vous avez une bonne idée de ce que je sais en matière de POO (pas grand chose donc ), vous n'aurez aucun mal à m'orienter vers les bonnes réponses/solutions...


En tout cas, ce fut une discussion vraiment passionnante et très instructive, si jamais vous avez d'autres précisions à ajouter, d'autres témoignages à partager, des bouts de code pour illustrer tel ou tel autre aspect intéressant de la POO, n'hésitez-pas une seconde, je resterez attentif à toute nouvelle contribution à ce topic...

Un très GRAND MERCI à tous pour votre participation éclairée !

à+