Discussion :

[Sébastien L]

Bonjour,

J'ai codé un système de news en PHP5 avec PDO via la méthode procédurale et j'aimerais repartir de 0 en utilisant la programmation orientée objets. J'ai lu le livre "PHP5 avancé, 5ème édition" mais après avoir parcouru les 50 pages dédiées aux objets je me sens encore perdu pour l'appliquer à mon système de news.

Pourriez-vous me guider en m'expliquant la structure des classes à construire, des méthodes à implémenter, des variables nécessaires,...?

Pour l'instant mon système de news est composé d'une partie administration permettant d' ajouter/modifier/supprimer/valider ou dévalider des news, afficher l'auteur d'une news, la date de publication et de dernière modification, le nombre de commentaires associés. Le système crée aussi automatiquement les miniatures de news. Les internautes peuvent voir les dernières news listées avec leur titre et un extrait de leur contenu ainsi qu'une petite miniature et la date de publication.

J'ai 2 tables: news & comment_news

news
-----
id
titre
contenu
pseudo
miniature
timestamp
timestamp_modification

comment_news
-----
id_commentaire
pseudo
texte
fk_news
date_pub
valide

Merci beaucoup pour votre aide

Seb

[Petibidon]

Salut,

L'objet n'est qu'une manière de structurer ses données (marrant cette manière qu'ont les programmeurs PHP de craindre l'objet alors qu'ils en manipulent à longueur de temps)

Dans ton cas, tes objets sont à peu près déterminés. Une news est un objet caractérisé par son ID, son titre, son texte etc.

Quant aux méthodes, tu peux avoir les setters qui vont te servir à vérifier que les données qui composent ton objet sont bien du genre attendu, et par exemple renvoyer une erreur si ce n'est pas le cas. Tout dépend de la manière dont tu veux structurer ton code.

Le problème de l'objet c'est que c'est souvent lié à la manière de chacun de structurer son propre code, c'est peut-être pour cela que c'est toujours assez flou de prime abord, et difficile à expliquer. Tout ce qu'il faut savoir, c'est que c'est plus simple que ça n'y parait, et ça n'a aucun rapport avec la magie vaudou. Il ne faut pas craindre l'objet mais simplement s'y habituer et penser son code autrement qu'en procédural.

[Edit]
Pour revenir à ton problème, les variables de tes objets sont déjà quasiment faites.
Logiquement, tu ajouteras dans la classe News un tableau d'objets "Commentaires" contenant les commentaires qui sont liés à cette news. Dans ta classe "Commentaires" par contre il n'est pas nécessaire de référencer fk_news puisque la liaison entre les classes est différente de la liaison dans ta DB.

[Sébastien L]

Merci Petibidon pour ta réponse

Pouvez-vous commenter la logique suivante?

Le système de news comptera une classe "news" et une autre "commentaires". Chaque classe est caractérisée par des attributs:

Classe News

• Attributs
  - id
  - titre
  - contenu
  - pseudo
  - miniature
  - timestamp
  - timestamp_modification
  - valide
  - commentaires_news

Classe Commentaires

• Attributs
  - id_commentaire
  - pseudo
  - texte
  - date_pub
  - valide

-> doivent-ils tous être déclarés public? (ou private, protected?)

Et pour les méthodes, j'imagine (mais je suis dans le flou):

Classe News

• Méthodes
  - ajouterNews();
  - modifierNews($id);
  - supprimerNews($id);

Classe Commentaires

• Méthodes
  - ajouterComment();
  - modifierComment($id_commentaire);
  - supprimerComment($id_commentaire);

Quant aux méthodes, tu peux avoir les setters qui vont te servir à vérifier que les données qui composent ton objet sont bien du genre attendu

Tu veux parler des méthodes _set() ?

Je suppose qu'il me faudra aussi un itérateur donc une classe implémentant la classe Iterator.

Merci,

ps: vous l'aurez remarqué, je suis débutant

Seb

[Petibidon]

Le principe de base de l'objet est l'organisation de son code. Ranger les choses au meilleur endroit pour les retrouver facilement et simplifier au maximum son travail.

Par exemple lorsque tu reçois des données provenant d'un formulaire, la première chose que tu fais, c'est de vérifier qu'elles ressemblent à ce que tu attends. Puis tu les transformes pour les envoyer vers ta base de données. De même lorsque tu récupères tes données depuis une base de données, tu les transformes pour les afficher.

Où sont faites toutes ces vérifications et transformations ? Bah dans un code procédural un peu mal fichu, tu trouveras ces opérations un peu n'importe où, noyé au milieu de milliers de lignes de code. Dans un code orienté objet, tu feras ces vérifications/transformations dans des méthodes de l'objet. Cela permet d'alléger la partie procédurale du code et de retrouver facilement le code de tes opérations dans le cas où tu devrais les changer.

En règle générale pour un objet de données, on limite au maximum l'accès aux membres (c'est à dire les variables qui caractérisent l'objet) en déclarant ces membres "private". Cela interdit d'accéder à ces variable de manière directe :

$monObjet->variable = "truc"; // ERREUR !

Du coup cela oblige à définir des méthodes propres à l'objet pour accéder à ces membres. Une méthode (appelée mutateur ou setter) pour définir la valeur de ton membre. Et une méthode (appelée assesseur ou getter) pour récupérer la valeur. Ces méthodes sont généralement appelées setVariable() et getVariable().

par exemple pour le titre de ta classe News :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class News{
	private $titre;
	...
	// mutateur de News::titre
	function setTitre( $valeur ){
		$this->titre = $valeur;
	}
	// assesseur de News::titre
	function getTitre(){
		return $this->titre;
	}
	...
}

Dans l'exemple ci dessus, les méthodes sont définies avec le code minimal. Lorsque tu programmeras ton truc sérieusement, la méthode News::setTitre() se chargera de vérifier que la valeur qui lui est passée ressemble à ce que tu attends puis de la transformer le cas échéant. La méthode News::getTitre() se chargeant de te renvoyer la valeur de News::titre dans un format qui te convient le mieux pour l'utiliser ensuite dans ta partie procédurale.

Attention aux méthodes __set() et __get() qui sont des méthodes magiques de surcharge et qui ne doivent être utilisées que dans des cas très précis et avec parcimonie (enfin ça c'est un avis perso)

Etant donné que je suis pas sur que mes explications soient super limpides, je poursuis pas plus loin pour le moment