Geek un jour, geek toujours !
|
Citation Voilà Davidbrcz pour info j'ai précisé la notion d'encapsulation et son esprit à la fin du tutoriel juste avant le qcm
reste plus qu'a faire la même chose dans le cours de C++
|
Because I can
Ville : Marseille
Pays : France métropolitaine
|
Bonjour bonjour !
Avant tout, et bien que je vais critiquer (peut être lourdement) l'article, je tiens quand même à dire que je comprends l'idée qui est derrière : l'auteur a voulu faire simple en s'adressant à des débutants. C'est louable, et dans certains cas, l'article arrive à atteindre son objectif. Pour cette raison, j'adresse remerciement et félicitations à M@teao21.
Si j'interviens ici, c'est parce qu'un de mes articles à été cité en contrepoint pour affiner certaines des notions présentées dans ce tutorial. Contrairement à ce que j'ai lu plus haut et qui semble présenter mes écrits comme destinés à des personnes plus avancées techniquement, la plupart des billets de mon blog sont eux aussi destinés à des débutants - c'est pourquoi je prends le temps de discuter longuement de notions comme l'encapsulation ou les 5 principes majeurs de l'architecture logicielle orientée objet. Le problème principal de mes article tient en un seul mot : vocabulaire.
On peut en effet me reprocher un vocabulaire abscons. Cependant, l'utilisation que j'en fait n'est guidée que par un seul désir : être correct dans ce que je présente. Il faut comprendre que comme Pascal en son temps, j'aurais aimé produire des écrits plus accessible mais que j'ai manqué de temps pour le faire. Simplicité et exactitude sont des concepts qui sont trop souvent radicalement opposés, et réussir à les rendre compatibles requiert du temps et du talent (je peux de temps en temps avoir le premier ; pou le second, j'ai arrêter d'espérer). Plutôt que de sacrifier l'exactitude, j'ai tendance à préférer sacrifier un poil de simplicité - tout en essayant quand même de rendre mon message clair et lisible. Je pense que j'y parviens au moins en partie dans l'article qui est cité plus haut par Davidbrcz.
Le tutoriel présenté, lui, sacrifie en partie l'exactitude sur l'autel de la simplicité. Le problème, c'est qu'ainsi il enseigne des choses qui, bien que partiellement correcte, n'en sont pas moins partiellement incorrecte. Je vais tenter d'en faire le tour.
Les problèmes
1) En partant du postulat qu'il existe une sorte de lien entre le objets tels qu'on les connait et les objets d'un programme informatique utilisant une architecture dite orientée objet, on commet une légère erreur de sémantique. Si comparaison il doit y avoir, c'est du coté des mathématiques qu'il faut se tourner, et non du coté du monde réel. Tout comme un objet mathématique (une fonction, un groupe, un intervalle dans un ensemble, ...), un objet "informatique" a des propriétés et ses comportements sont régis par des règles. Les objets du monde qui nous entoure n'ont pas ces limitations (chaise.deplacer() n'a guère de sens dans le monde réel : une chaise ne se déplace pas toute seule), ce qui rends la notion d'objet "informatique" plus floue que claire. Cependant, d'autres avant moi ont démontré que la notion d'objet mathématique est un sur-ensemble de la notion d'objet "informatique" - si on peut décrire entièrement le second en utilisant le langage mathématique, l'inverse n'est pas vrai.
A la décharge de l'auteur, trop de textes introduisent la notion d'objet par ce biais, et les introductions plus précises sont (trop ?) souvent réservées à une élite qui travaille d'arrachepied sur le sujet (les Robert C. Martin et consorts). De plus, dès qu'on recherche sur internet des textes plus avancés on tombe trop aisément sur des articles en anglais - ce qui rends le sujet encore plus obscur pour les non-anglophones.
Par contre, à sa charge, il est nécessaire lorsqu'on écrit un article destiné à des débutants de faire cette démarche de recherche afin de ne pas s'enferrer dans une simplification outrancière et de s'assurer qu'on maitrise bien le sujet de l'article.
2) Évidemment, le message s'adressant à des débutants, il est nécessaire qu'il soit accompagné de7 code. Nécessaire ? Non, pas forcément. Le code est dangereux, car il introduit des notions qui sont propre au langage et non au concept sous-jacent. Parmi elles : la notion de contrôle d'accès - symbolisé par les mots-clefs classiques "public", "protected", "private". Etonamment, ils reviennent de manière incessante dès qu'on parle de programmation objet - et pourtant, ils n'ont strictement rien à voir avec la notion même d'objet. Je vais y revenir plus longuement dans le (3), mais il me semble important d'attaquer ce sujet dès maintenant.
Je comprends l'idée de base, qui est de dire qu'une explication est toujours plus claire si elle est illustrée. C'est vrai dès lors que les illustrations sont correcte. Si les illustrations ne sont pas correctes, au mieux elles entrent en conflit avec le texte, au pire le texte les accompagne et devient incorrect lui-même. C'est là que le code est dangereux : puisqu'il fait intervenir des notions qui sont propres à un langage, il demande des explications qui lui sont propres et détourne ainsi l'abstraction présentée à son profit. De fait, ce n'est plus le concept qui est la star de l'article mais le code, et le code est nécessairement éloigné du concept.
Je ne dis pas qu'un tutoriel de ce type ne doit pas contenir de code source. Dans bien des cas, ce code source peut être source de compréhension car il devient une illustration cohérente et correcte du concept. Comment arrive-t-on à cet état de grâce ? Principalement en respectant une structure simple : expliquer, puis préciser par un exemple concret. C'est (et je ne prends pas cet exemple au hasard) ce qui est fait dans le GoF (Design Patterns -- Elements of Reusable Object-Oriented Software). Chaque description commence par une explication souvent importante en taille et se termine par un exemple de code qui montre le principe en action. Ainsi, les particularités du code sont (si nécessaire) explicitées en dehors de l'explication principale et le code ne pollue donc plus cette dernière.
Mais alors, comment illustrer de manière correcte des informations qui peuvent être complexes ? Une bonne solution serait d'utiliser des diagrammes (on peut, par exemple, utiliser une notation proche des diagrammes de classe UML ; ces derniers sont complexes, mais des simplifications peuvent être apportées pour en améliorer la lisibilité).
3) Si j'y suis allé avec une certaine force sur cette histoire de code plus pollueur que salvateur, c'est qu'en abordant les concepts via le code, l'article commet une erreur de taille : il semble s'appuyer sur le fait que la notion d'objet et celle d'encapsulation sont étroitement mêlés. J'aurais aimé que la vie soit si simple. Hélas, c'est entièrement faux : le concept d'objet et le concept d'encapsulation ne sont pas lié de manière évidente. Pour utiliser des mots qui font rage dans les cercles semi-instruits, ce sont deux concepts complètement orthogonaux - une autre manière de dire qu'ils se croisent en un point défini mais que leur route se sépare aussitôt. La raison de cette erreur est - je viens de l'aborder - le code lui même. En introduisant un langage qui permet de définir une classe, on introduit en même temps tous ces parasites syntaxiques. Parmi ces derniers, tout ce qui a trait au contrôle d'accès dont j'ai parlé un peu plus haut. Dès lors que le contrôle d'accès entre en jeu, il devient nécessaire de parler d'encapsulation.
Histoire de démontrer que l'encapsulation n'a rien à voir avec la notion d'objet, nous devons revenir à ce qu'est un objet "informatique". Comme dit plus haut, il s'agit d'une entité mathématique qui est définie par un certain nombre de propriétés dites intrinsèque (parce qu'elles sont "à l'intérieur de l'objet") et sur lequel il est possible d'appliquer certaines opérations. Prenons l'objet "droite dans un repère orthonormé". Cette droite est définie par son équation y = a.x + b ainsi que par les deux valeurs a et b ; parmi les opérations disponibles, il y a celle qui permet de calculer une valeur de y pour une valeur donnée de x. On peut en imaginer bien d'autres (projection dans un autre repère, calcul de la position des intersections avec les axes du repère, etc).
Question : qu'est ce qui est public, privé ou protégé dans cette définition de l'objet droite ? Afin de vous simplifier la réponse, je vais vous la donner : rien. Le raisonnement est simple : appliquer un quelconque mécanisme de contrôle d'accès sur cette définition n'a strictement aucun sens. C'est évident pour tout ce qui concerne les opérations appliquées sur les objets "droite". Pour un programmeur, c'est moins évident lorsqu'on parle des propriétés - principalement parce qu'on est encore pollué par des notions héritée du code, j'ai nommé les propriétés au sens C# ou Java (d'autres langages sont coupables de se vautrer dans l'a-peu-près linguistique). Pourtant, est-ce que dire "l'équation de la droite est [privé|protégée|publique] a un sens ? Qu'en est-il alors de a et b ?
Encore plus simple - et un peu plus éloigné des mathématiques pour ceux qui sont fâchés avec cet outil. On définit une objet qui représente un mot du dictionnaire. Parmi les propriété de cet objet, il y a par exemple le terme (le mot lui-même) et son genre (masculin, féminin, neutre). En quoi le fait de rendre l'une ou l'autre de ces propriété [privée|protégée|publique] change en quoi que ce soit la représentation d'un mot du dictionnaire ?
Bien évidemment, et j'entends les ronchons au fond de la salle, certains se posent la question du lien qui existe entre encapsulation et notion d'objet. Instinctivement (et plus probablement parce qu'on nous l'a dit), on sent qu'un tel lien existe. C'est vrai - mais il n'est pas là où vous pensez. En fait, ce n'est pas avec la notion d'objet qu'est liée la notion d'encapsulation, mais avec la notion d'architecture orientée objet. C'est tout le sujet de l'article cité par David u peu plus haut. L'encapsulation est la base même de l'architecture orientée objet moderne, et cette dernière se base sur la notion d'objet pour exister. Mais la notion d'objet elle-même (et ce qu'elle implique) n'a pas de lien avec l'architecture orientée objet (OK, c'est plus difficile à prouver, mais c'est faisable). C'est alors que le concept de contrôle d'accès prend une partie de son sens. Ce contrôle d'accès, qu'il soit explicite (PHP, C++, Java, C#...), non existant (python?) ou implicite (pas d'exemple de langage ; mais je peux aisément en deviser un) est une aide au programmeur. En l'utilisant à bon escient, il s'assure de quelque chose d'essentiel : la validité de l'invariant. Ouch. Encore un mot barbare. En fait, derrière cette expression un peu étrange, on retrouve un concept fort simple : pour qu'un programme soit valide, il est nécessaire de s'assurer que tous les objets qui composent ce programme soient valides. Pour qu'un objet soit valide, il faut qu'à tout moment les propriétés qui le composent aient des valeurs qui sont cohérentes. C'est cela l'invariant : la cohérence des propriétés de l'objet. Si les propriétés sont cohérentes entre elles, l'invariant est dit "respecté" ; dans le cas contraire, il est dit "violé".
Reprenons notre objet "mot du dictionnaire". Supposons que le terme soit "Femme" et le genre soit "masculin" : nous savons que le substantif "femme" est féminin - il y a donc un problème évident, une incohérence : l'invariant de l'objet a été violé.
Les mécanismes de contrôle d'accès ont un but unique : s'assurer que quelque soit l'opération appliquée à l'objet, son invariant soit respecté à tout moment. Pour cela, la sagesse populaire dit que les propriétés de l'objet sont déclarées comme étant privées à cet objet - de telle sorte qu'il soit impossible de violer l'invariant - ne serait-ce que momentanément - en modifiant une ou plusieurs propriété de l'extérieur. L'application de cette sagesse populaire est la première phase de l'encapsulation - cette phase est généralement nommée "information hiding", ou "dissimulation d'information". En soit, cette phase n'est pas suffisante pour aboutir à une bonne architecture objet - c'est pourquoi, dans mes écrits, je fustige régulièrement les accesseurs (fonction getX()) et mutateurs (setX()) qui fleurissent dans le code dit 'objet'. Il faut lui associer ce qu'est réellement l'encapsulation, c'est à dire l'intégration dans la définition de l'objet des opérations qui lui seront appliqués - ce que j'ai appelé dans mon article les comportements. Si les opérations qui doivent être appliquées à un objet sont effectuées en dehors de cet objet, alors le fait que les propriétés soient dissimulées n'a pas d'intérêt - puisqu'il faudra probablement des mutateurs pour sauvegarder les informations calculées, et qu'il faudra en outre transférer une partie du contrôle de l'invariant de l'objet à l'extérieur de celui-ci. Je pourrait mettre ces deux phrases en gras, tant elle résument à elle seules l'intégralité de l'article que j'ai écrit.
Juste pour terminer ce point (et je ne vais pas m'étendre vraiment su le sujet) : non, il n'est pas conseillé de définir ses variables "protected". Si possible, c'est à éviter. En fait, hériter d'une classe doit se faire en respectant aussi l'invariant de cette classe (pour des raisons presque philosophiques que je n'aborderais pas ici ; ceux qui en ont le courage peuvent effectuer certaines recherche sur le net sur le mot clef 'LSP' ou 'Liskov Subsitution Principle') et par conséquent se doivent de traiter leur classe mère comme une boite noire.
4) Une présentation de la notion d'héritage un peu farfelue ; d'aucuns dirait "datée". Avec cette définition, le fait qu'un carré soit un rectangle particulier imposerait que la classe Carré dérive de la classe Rectangle. Problème : les conditions de respect de l'invariant sont différentes (H et L sont les deux grandeurs associées à un rectangle ; dans la classe Rectangle, l'invariant est respecté quelque soit H et L ; dans la classe Carré, H et L doivent être identiques). Les opérations qu'on peut appliquer à un rectangle ne peuvent pas être appliquées à un carré. On dit dans ce cas que le contrat (à peu de chose près "la définition complète") du carré est différent du contrat du rectangle. Qui dit contrat différent dit pas de lien d'héritage possible.
Il y a donc des subtilités dans ce lien d'héritage qui ne peuvent être simplifiées à la formulation choisie par l'auteur.
Conclusion
Voilà, je crois que j'ai dit à peu près tout ce que j'avais à dire. A certains, ce pavé pourra paraître indigeste. Encore une fois, j'aurais aimé le simplifier à outrance, mais je n'ai guère le temps de le faire. Pour finir, après avoir critiquer les points litigieux du tutoriel, j'ai l'obligation de remarquer certains très bons points :
* une très bonne définition de la différence entre les notions de classes et d'objets/instances.
* une introduction efficace sur les éléments de syntaxe du PHP qui permettent un support plus aisé des techniques de programmation orienté objet.
* une bonne mise en garde de l'utilisateur : non, la POO n'est pas la panacée. La POO est, comme la programmation "procédurale" (langage C, Pascal...), un outil dans la boite à outil du programmeur. Bien utilisé, cet outil peut avoir des conséquences fortes sur la qualité du code produit. Mal utilisé, l'outil peut être un problème au lieu d'être une solution. Pire : l'outil est livré sans mode d'emploi. La qualité logicielle est un secteur en pleine effervescence. De nombreux chercheurs tentent de définir comment bien programmer, et comment écrire du bon code. A l'heure actuelle, il n'existe pas de réponses à ces questions pourtant terriblement importantes.
Voilà, je vous remercie de m'avoir lu. Si vous avez des questions à poser, n'hésitez pas - je ferais de mon mieux pour y répondre, malgré le fait que je n'ai à l'heure actuelle que très peu de temps à y consacrer.
|
Éditeur
Avis : Décevant
|
J'avoue être quelque peu déçu par cette introduction à l'OO. Cela fait quelques années maintenant que je code (d'abord grâce à ce site, ensuite à la doc et l'expérience), et j'ai finit par comprendre les "limites" de la programmation procédurale. J'ai donc essayé de me pencher un peu sur la POO, sans vraiment trop de succès. Cependant, j'en ai quelques notions (bien qu'incapable de produire le moindre code). Bref, je m'étais dit qu'enfin, grâce à ce tutoriel, mon ignorance toucherait à sa fin. Mais la vie n'est pas ou noire ou blanche; elle est plutôt grise. Tout comme ce tutoriel.
Les notions ne sont que survolées, les exemples incomplets. Je comprends bien que ceci n'est qu'une initiation, et qu'il existe sur ce même site un tutoriel plus avancé sur cette notion d'OO. Mais dans ce cas, pourquoi ne pas avoir, après quelques retouches adéquates (je n'ai jamais réussi à aller au bout du tutoriel de vyk12), passé ce tuto en officiel, un lien en annexe pointant dessus? Pour moi, faire une telle initiation à la Programmation Orientée Objet, c'est comme demander à un peintre en bâtiment de reproduire la Joconde avec ses rouleaux. Il peut le faire, mais à quel prix?
Pire, certaines parties disent, en gros, "voila, maintenant débrouillez-vous!". Mais si, celle par exemple où tu dis, m@teo21, qu'il faut récupérer les données venant de sa BDD et de travailler dessus. Oui, mais encore? Comment? Quels sont les moyens qui existent pour faire ça? Il me semble qu'un des buts de la POO est de pouvoir réutiliser ses codes. Donc à priori, de réutiliser sa connexion à la BDD sans avoir à se refarcir tout le code à chaque fois qu'on a besoin de récupérer des données. Il aurait donc été bien de dire comment faire, plutôt que laisser un simple "// Récupérer en base de données les infos du membre". D'autant que là, on perd tout l'intérêt du site du zér0, qui explique tout de zéro, en partant du principe que celui qui lit n'y connait rien. Là c'est plutôt "débrouillez-vous". Et c'est dommage.
Enfin je terminerai sur la dernière partie, que j'avoue n'avoir pas compris: en quoi le fait de mettre ses variables en public est-il dangereux, dans la mesure où c'est le codeur lui-même qui les appelle? C'est comme demander à Robinson Crusoé de mettre ses bien dans un coffre-fort; il est tout seul sur l'île, qui va venir le voler? Je trouve cette partie particulièrement peu claire, et l'exemple ne me convainc pas, puisqu'il parle à fortiori d'une donnée venant d'un input (je ne vois pas comment renseigner un mail autrement), et qu'il faut, dans 99% des cas, vérifier l'information venant d'un input. Donc public ou private, à partir du moment où on vérifie au préalable...
Cependant, on apprend quand même des choses quand on y connait rien, et comme d'habitude c'est agréable à lire.
|
|
|
Ca devient ridicule, pourquoi la France s'attarde avec le php... vous vous faites du mal
Code : PHP 1
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
34
35
36
37
38
39
40 | <?php
class Membre
{
private $pseudo;
private $email;
private $signature;
private $actif;
public function envoyerEMail($titre, $message)
{
mail($this->email, $titre, $message);
}
public function bannir()
{
$this->actif = false;
$this->envoyerEMail('Vous avez été banni', 'Ne revenez plus !');
}
public function getPseudo()
{
return $this->pseudo;
}
public function setPseudo($nouveauPseudo)
{
if (!empty($nouveauPseudo) AND strlen($nouveauPseudo) < 15)
{
$this->pseudo = $nouveauPseudo;
}
}
}
$toi = new Membre()
$toi->getPseudo()
$toi->actif // erreur (actif est de caractère privé)
$toi->setPseudo("Jacob")
$toi->bannir()
$toi->pseudo
?>
|
Équivalent Ruby (et Python serait à peu près aussi simple que Ruby)
Code : Ruby 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 | class Membre
attr_reader :pseudo # attribuer_liseur pour pseudo (créé une méthode nommée pseudo qui renvoi la valeur de @pseudo)
def envoyerEMail titre, message
mail @email, titre, message
end
def bannir
@actif = false
envoyerEMail 'Vous avez été banni', 'Ne revenez plus !'
end
def pseudo= pseudo # pas besoin de l'appeler nouveauPseudo car la variable du pseudo associé à l'objet porte un "@"
@pseudo = pseudo unless pseudo.empty or pseudo.length > 14 # traduction : @pseudo = pseudo sauf si pseudo.vide ou pseudo.taille > 14
end
end
toi = Membre.new # création d'un objet de classe Membre
toi.pseudo # appelle la méthode pseudo créée par attr_reader qui renvoi la valeur de @pseudo (nil pour l'instant) nil <=> null
toi.actif # cause une erreur car la méthode actif n'a été définie d'aucune façon
toi.pseudo = "Jacob" # appelle la méthode pseudo= afin de modifier le pseudo tout en respectant les conditions sur sa taille
toi.bannir # appelle la méthode bannir
toi.pseudo # renvoi "Jacob"
|
|
|
Cette partie était tellement attendue, et depuis tant de temps, sur un si gros morceau que celui de la POO PHP que forcément les critiques fusent!
Pour tout vous dire, j'ai une question, mais aussi un cas de conscience qui se pose à moi... Est-ce qu'une partie POO bien documentée, complète et allant au fond du sujet sera disponible dans le futur livre du Zéro sur le PHP? Et uniquement dans le livre...
J'espère que non!
Attention, attention gardons à l'esprit ce qui a fait le succès de ce site!
Je ne veux pas être mauvaise langue, je suis un zéro depuis qqes années déjà et un souscripteur de la première heure ( livre sur le C... ), mais j'avoue que j'ai un peu peur.
J'attends avec impatience les futures mises à jour de ce tuto. Je suis un zéro mais je suis curieux, Mateo apprends moi plus de choses, déchaine la puissance de la poo devant mes yeux ébahis 
et alors j'achèterai le livre 
My software never has bugs....It just develops random features!
|
|
J'ai bien aimé ce tutoriel qui est compréhensible pour les débutants (et je suis content que les tutoriels sont mis à jour).
Il faudrait une suite avec des exemples concrets pour les zéros. C'est en pratiquant pas à pas que j'ai appris le plus.
Merci d'avance...
|
Ville : Avesnes-sur-helpe
Pays : France métropolitaine
|
Merci pour cette introduction à l'orienté objet  .
Je vais déjà essayer de m'entraîner avec ce que j'ai apprit dans ce chapitre puis ensuite j'irais lire le tutoriel de vyk12 sur l'orienté objet qui à l'air très complet .Au faite j'ai une question qui me passe par là tête, est ce que le tutoriel de vyk12 sera édité au format papier ?
Cordialement robin.
|
rien ne sert de courir
|
C'est sans conteste le meilleur cours de POO que j'ai trouve jusqu'ici. Une fois de plus M@teo21 rend le dedale de la programation un vrai plaisir grace a une approche 100% pedagogique. Merci pour tes cours, on pourrait presque croire que la programmation est devenue un jeu d'enfant. Il y a encore 4 ans, je ne comprennais meme pas le principe de Code : HTML et Code : HTML en HTML et aujourd'hui je develope et administre des 10zaines de site internet php. D'etudiante en droit, je suis devenue web developeur de profession. Et tout a commence ici, sur le site du zero. En posant les bases de la programmation et en nous donnant les outils pour pouvoir ensuite chercher plus loin... Tu m'a donne un metier, que j'adore.
Encore, Merci...
PS: Tres peu de tuto sur le site du zero sont a la hauteur de ceux de M@teo21, alors pour ceux qui redigent, bien que votre travail soit remarquable et tres louable, s'il vous plais impregnez vous de sa methode pour mettre la programmation au niveau de tous... Merci
|
|
|
Les choses ne sont pas aussi simples quand on a fait de que de la programmation procédurale (Pascal,...) avant de passer à la programmation orientée objet...D'ailleurs cela peut constituer un handicap, par exemple, on programmation de type procédural il faut construire le programme de façon modulaire en créant pas mal de fonctions et des procédures (manipuler des pointeurs, créer des listes,...) alors qu'on programmation orientée objet le boulot est presque mâché à travers des API (je ne sais pas si PHP dispose déjà d'une bibliothèque assez fournie d'API)...Et en utilisant les propriétés des objets tels que l'héritage, l'encapsulation, le polymorphisme,...on fait des miracles...J'ai beaucoup apprécié la manière dont le tutoriel a présenté la programmation orientée objet (et d'une manière général l'ensemble des autres tutoriels présentés par l'auteur)...Surtout qu'il ne change rien à sa pratique ou bien à sa pédagogie...Je pense que si l'on veut développer une approche théorique assez poussée de la POO on peut consulter d'autres sites ou des ouvrages très spécialisés...En tout cas merci pour ce travail!
|
|
|
saluut tous le monde..tres sympa tous ces cours, intrucstifs...blablabl..bref SUPER!!
mais
il manque un tp là,nan? je suis d'accord avec certain, refaire les tp qu'ont a travaillés en POO...je vais essayer ..
@ bientot sur le forum...
et merci!!!
|
Taymiri
Ville : Evron
Pays : France métropolitaine
|
Bonjour ! 
Je pense que ce tuto à encore besoin d'être retravaillé  mais il est quand même très bon !
Un TP ? 
|
Avis : Très bon
|
Mille merci, grace a ce tutoriel, j'ai enfin compris ce qu'etait exactement un objet et une classe!!Vraiment une excellente facon d'enseigner, felicitation a l'auteur et merci de prendre le temps de partager tes connaissances!
|
Le programmeur fou
|
M@atéooooo??? C'est quoi ça ! Hein faut travailler un peu pas copier coller chapitre du C++ nah mais ho ! (Non je rigole déjà que de faire un tuto comme ça c'est long mais en faire un autre sur exactement la même chose... trop fatiguant  )
(je sais cette userbar est complètement nulle, nulle a en crever mais moi, j'aime bien !)
|
|
Bonjour,
Je n'arrive pas à récupérer en base de données les infos du membre.
Pourtant je fais une connexion à Mysql en PDO et une requête avec query('SELECT etc...') comme j'ai appris précédemment dans le chapitre MySQL.
J'ai l'impression que à l'intérieur de la fonction __construct on ne peut pas se connecté à la $bdd à l'aide PDO et faire par la suite une requête.
Y a t-il une façon particulière de charger la base données dans une fonction __construct?
Dans l'attente d'une réponse.
Je vous en remercie d'avance.
Code : PHP 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | <?php
class Membre
{
public function __construct($idMembre)
{
// Récupérer en base de données les infos du membre
// SELECT pseudo, email, signature, actif FROM membres WHERE id = ...
// Définir les variables avec les résultats de la base
$this->pseudo = $donnees['pseudo'];
$this->email = $donnees['email'];
// etc.
}
...
?>
|
|
|
|
Salut orquato,
il n'y a pas de formule magique pour charger ta base de données dans le __construct.
Mais tout de même je te conseille de faire une classe entière dédié à la manipulation de la base de données, si jamais ton projet atteint une certaine taille.
Moi par exemple je travaille de la facon suivante:
Code : PHP 1
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
34
35
36
37
38
39
40
41
42
43
44
45
46
47 | <?php
/**
* Classe pour manipuler la base de données
*/
class MysqlCore extends Core{
/**
* Contient une instance de cette classe, pour éviter d'ouvrir
* plusieurs fois la base de données.
*/
private static $_oInstance = null;
/**
* Contient ma "connexion" de la base de données
*/
private $_oMysqli = null;
/**
* Initialisation de la base de données.
* L'access est restreint a cette classe, d'où le private.
*/
private function __construct() {
$this->_oMysqli = new mysqli( parent::_getMysqlHost(),
parent::_getMysqlUser(), parent::_getMysqlPassword(),
parent::_getMysqlDatabase() );
}
/**
* Et pour finir utiliser la connexion dans d'autres classes
* S'utilise de la facon suivante : MysqlCore::getInstance();
*/
public static function getInstance() {
if(self::$_oInstance == null) {
self::$_oInstance = new MysqlCore();
}
return self::$_oInstance;
}
//Ici quelques methodes pour manipuler la base de données
public function select($query) {
//Ici tu développe un peu ce qui se passe en cas de select
}
public function insert($query) {
//Pareil pour le insert etc.
}
}
|
Voilà pour la classe qui manipule la base de données, passons maintenant a ton problème:
Code : PHP 1
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 | <?php
/**
* Classe pour manipuler les Membres
*/
class Membre {
/**
* Connexion a ma base de données
*/
private $_oMysql = null;
/**
* Établi un select pour charger un membre
*
* @param int iMemberId
*/
public function __construct($iMemberId) {
//On prend l'instance de notre classe MysqlCore
$this->_oMysql = MysqlCore::getInstance();
//Notre query pour charger les informations du membre
$query = "SELECT pseudo, email, signature, actif FROM membres WHERE id = '". $iMemberId ."' LIMIT 1";
//On lance la méthode select de MysqlCore
$aResult = $this->_oMysql->select($query);
}
}
|
En ésperant t'avoir pu aider. Mais bon je ne suis pas venu pour ca d'origine, au fait j'ai juste voulu laisser un commentaire concernant le tutorial.
J'avoue que je n'ai pas tout lu, mais je pense que dès le début tu ne dis pas assez les avantages que donne la POO.
Les premiers points importamts a dire la dessus sont:
- Cela simplifie la structure du code source d'un projet
- Facilite a d'autres personnes de comprendre le code
- Les bugs sont plus facile a corriger, le projet est plus simple a maintenir
- On peut utiliser des UNIT Tests pour créer un environnement virtuel pour tester toute possibilité et éviter un maximum d'erreurs du programme
Bref, au début de ton tutorial tu dis que ca ne va changer le site, mais au fait si, ca change tout. Certes le code n'est pas plus performant en lui même, par contre la maintenance du code ainsi que la probabilité de tomber sur des erreurs est minimale.
Je tenais juste a faire le commentaire, sinon - joli tutorial, dans mes débuts ca m'a beaucoup aidé (la partie procédurale, le POO je l'ai appris a mon travail ;))
|
Honneur à l'innocence
Avis : Très bon
Études : Lycée Berthollet - Annecy
|
Je reste quand même un peu mitigé en ce qui concerne ce chapitre.
J'ai compris où M@teo où voulait en venir, mais pour ce qu'il s'agit de la pratique, je pense me diriger vers un chapitre un peu plus complet et explicatif.
M'enfin, je ne vais pas critiquer, car c'est un des seuls chapitre où j'ai eu quelques difficultés ! Merci :).
|
Avis : Très bon
|
Salut tout le monde
j'ai lu attentivement ce tutoriel mais je ne comprend pas vraiment l'intérêt de la POO car a la suite de ce chapitre tout ce que je comprend c'est que tout ce qu'on a appris en php pour les variables et les fonctions sont inutiles si on se sert de la POO puisque la POO c'est mieux c'est ça?
Donc maintenant si on veut vraiment programmer en php il faut aller lire l'autre cour "la POO en php" c'est ça?
Allez l'OM
|
|
|
je suis consterné vue que les notions de base dans ce chapitre ne sont que survolées, mais aussi les exemples sont incomplets.
C'est le seul chapitre où j'ai eu des difficultés même après une deuxième, troisième, quatrième , bref plusieurs lectures...Tout est flou pour un débutant comme moi en POO.
|
Avis : Décevant
|
Je trouve ce chapitre très décevant  et ce n'est pas un troll. En effet, la POO devrait occuper une partie entière ! On apprend le principe, on le comprend très bien mais qu'en est-il de l'utilisation de la POO ! son intérêt parait minime et peu de personnes sur ce site apprennent le PHP dans le but de distribuer le code de leur site. Un TP sur la POO aurait été le bienvenue.
Sur ce, le reste du tutoriel est très bien, une note de déception sur le dernier chapitre...
|
Appelez moi Thibault !
|
Citation : EaglesebJe trouve ce chapitre très décevant et ce n'est pas un troll. En effet, la POO devrait occuper une partie entière ! On apprend le principe, on le comprend très bien mais qu'en est-il de l'utilisation de la POO ! son intérêt parait minime et peu de personnes sur ce site apprennent le PHP dans le but de distribuer le code de leur site. Un TP sur la POO aurait été le bienvenue.
Sur ce, le reste du tutoriel est très bien, une note de déception sur le dernier chapitre...
Il ya un tuto ifficiel sur le siet du zéro sur l'OO --"
Développeur web :HTML5 et CSS3, PHP(POO, MVC) et MySql (et SQL), javascript (Jquery et AJAX), SEO, webdesign (charte graphique + integration) et en linux (serveurs). Amateur bien sûr.
(\ /)
( - -)"
c(")(")
Merci à WarpShadow, SofEvans et Pouet même si ce mec est complètement décourageant.
Anti spam !!
http://megafr.com/the-walking-dead-sai [...] ng-megaupload
|
Davidbrcz
Zaroide
Trouvez une formation
Suggestions
Facebook
Google+