[POO] Liste de référence

Version imprimable

Bonjour,

Je suis en train de coder une classe pour gérer des articles par rapport à la bdd.

J'ai une classe Article pour représenter les articles eux-même, et une classe ArticleManager qui travaille avec des objets Article.

Voici la structure de mes classes pour le moment :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class Article { var $id; var $title; var $date; var $author; var $content; var $category; var $id_category; } class ArticleManager { function addArticle () {} function removeArticle () {} function updateArticle () {} function getArticleById () {} }
Mais voilà, il y a un moment où il faudrai que je récupère seulement la liste des articles disponibles. Par exemple je voudrais pouvoir récupérer la liste de tous les articles qui appartiennent à une certaine catégorie.

Première chose : cela aurait-il une consistence quelconque de ne récupérer que la liste de id et titre des articles sans récupérer les articles eux-même ?

deuxième chose : les éléments de la liste renvoyée par la méthode sont de quelle type ? Sont-ce des objet Article où je ne remplis que quelques champs, ou alors dois-je créer une nouvelle classe ArticleHeader (par exemple) et ma méthode renverrait une liste d'instance de la classe ArticleHeader.

dernière choses : si je crée une nouvelle classe je dois l'appeller comment ? Et ma méthode je l'appelle comment ? getArticleListByCategory ou getListArticleByCategory ou encore autre chose ?

Je précise que je suis en php4.

Merci d'avance.

Perso j'aurais une classe ArticleLight (on vas dire sa) juste pour les listings.

Bon la tu n'as pas trop de propriétés dans tes articles donc sa n'à pas trop d'incidence mais si tu à des articles avec des descriptions qui vont piocher dans 5 - 6 tables différentes c'est plutot utile de ne récupérer que le strict necessaire pour les listings.

Et ensuite effectivement une classe article avec la description complète.

getListArticleByCategory ou getArticleListByCategory c'est chapeau blanc et blanc chapeau ;)

Mais j'opte pour getArticleListByCategory.

Quand à savoir ou mettre ta méthode, selon ta configuration actuel se serait dans articlemanager, non ?

qui te renverrait une reference de tableau (ou un objet avec le tableau encapsuler à l'intérieur), car tant qu'à faire évitons la copie de valeurs exessive.
Ce tableau contiendrait donc une série d'objet ArticleLight.
Donc au final il y'aurait quelque chose comme cela :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 class ArticleLight{ } class Article extends ArticleLight{ } class ArticleManager { function addArticle () {} function removeArticle () {} function updateArticle () {} function getArticleById () {} function getArticleListByCategory(){} }
Par curiosité, dans ta configuration actuelle, si j'ai correctement compris, le constructeur de Article ne fais rien, si ce n'est initalisé les propriétés à NULL (ou autres) ?

Voilà Voilà, qu'en pensent les autres ?

bye

23/12/2005, 01h23
Celelibi

Citation:

Par curiosité, dans ta configuration actuelle, si j'ai correctement compris, le constructeur de Article ne fais rien, si ce n'est initalisé les propriétés à NULL (ou autres) ?

Oui en effet la classe article n'est en fait qu'une structure de donnée.
Si il y a quelque chose de mal avec ça, il ne faut pas hésiter à me le dire, je n'aurais des cours de POO que dans quelques années. :P

En fait je comptais créer une classe ArticleWithCommentManager qui hérite de ArticleManager. Pour le manager pas de problème. Le problème se pose plutôt pour la classe ArticleWithComment qui devait hériter de la classe Article. Cette classe n'aurait en fait qu'une seul propriété en plus qui contient la liste des commentaires qui portent sur l'article.
Mais si on suit ton raisonnement, je devrais aussi avoir ArticleWithCommentLight qui hériterait de ArticleLight avec comme popriété supplémentaire le nombre de commentaires de l'article (car ça fait parti des méta-données que je veux afficher avec la liste des articles).
Donc ArticleWithComment devrait hériter à la fois de Article et de ArticleWithCommentLight.
Et ça je crois que même php5 ne le permet pas. Mais peut-être y a-t-il des astuces pour avoir un pseudo héritage multiple.

PS : si on m'avais dit ne serait-ce que l'année dernière qu'un jour le manque de typage de php me ferait défaut par rapport à l'Ada, je ne l'aurais jamais cru.

Citation:

Oui en effet la classe article n'est en fait qu'une structure de donnée.
Si il y a quelque chose de mal avec ça, il ne faut pas hésiter à me le dire, je n'aurais des cours de POO que dans quelques années.

C'était juste une question car pour moi aussi les questions de conception sont assez nouvelles et jusqu'à présent j'ai utiliser des constructeur avec des surcharges.

Et l'idée c'est que si j'ai un argument, je suppose que c'est un ID et je vais lire dans la BDD, si j'en ai pas je veux juste une structure.

C'était juste pour comparer, car en faits je n'utilise pas de manager à part. Le manager et la structure sont confondus.

Citation:

Et ça je crois que même php5 ne le permet pas.

Effectivement PHP5 ne permet pas l'héritage multiple.

Citation:

Mais si on suit ton raisonnement, je devrais aussi avoir ArticleWithCommentLight qui hériterait de ArticleLight avec comme popriété supplémentaire le nombre de commentaires de l'article (car ça fait parti des méta-données que je veux afficher avec la liste des articles).

Oui effectivement on pourrais faire une classe pour obtenir les articles + commentaires indépendamment d'une classe qui ne récupère pas les commentaires.
Sauf que si l'on va au bout de cela on risque d'avoir au final plein de classes dans tout les sens.
Et je craint que l'on s'y perde plus qu'autre chose.

Alors que le fait d'avoir une classe ArticleLight et Article c'est dans ce cas la plutot interessant car en faits à partir de article tu peux étendre des classes pour créer des porduits de type alimentaires, vestimentaires ect...
Bref je trouve qu'il y à un vrai lien de spécialisation entre ces deux classes.

A contrario la classe ArticleWithComment n'aurais pour but que de pouvoir plugger deplugger facilement les commentaires qui sont des propriétés et pas vraiment des raisons de spécialisation.
Mais je ne sais pas si cela en vaut le coup pour de tels projets...
En tout cas l'idée me plait d'un certain point de vu.

J'aurai plutot envie de dire que le nbre de commentaires est une propriété de ArticleLight. Et que les commentaires en eux mêmes sont une propriétés de Article.

En clair j'aurais envie de faire quelque chose comme cela.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 class ArticleLight{} class Article extends ArticleLight{} class Commentaires{} // représente une liste de commentaires class ArticleManager{ function addArticle () {} function removeArticle () {} function updateArticle () {} function getArticleById () { // une requete pour lire notre produit $Article = new Article(); $Article->Patati = $res["patati"]; $Article->commentaires = $this->getCommentsFromArticles( $IdArticle ); } function getArticleListByCategory(){ // une requete pour lire nos produits + le nbre de commentaires par produit $Article = new Article(); $Article->Patati = $res["patati"]; $Article->nbCommentaires = $res["nbcommentaires"]; } function getCommentsFromArticles(){}// retourne une instance de commentaires }
Mais bon prends cela avec précaution parce qu je suis un peu dérouté par ta conception et je n'arrive pas à voir comment cela peut évoluer avec plus de fonctionnalités...

Bye

Ps: J'espère que je reste assez clair car j'ai l'impression d'avoir été très brouillon et pas super ordonné.

23/12/2005, 10h14
siddh
salut,
effectivement tu peux pour tes listes n'avoir qu une classe "light" car si tu as beacoup d'articles, ca evitera de surcharger la mémoire.

Par contre, peut etre qu'un simple tableau associatif ferais l'affaire ?
Code:

1 2 3 $articles = array(); $articles[] = array("id" => 1,"libelle" => "truc"); ....
Surtout si tu n'y met pas de méthodes.
Ca sert pas a grand chose de créer des objets pour en créer, il faut qu'il y ai une vraie utilité.

Du coup ca pourrais etre ta classe ArticleManager qui te retourne ce tableau.

En ce qui concerne l'héritage multiple, php le gère comme java, en passant par des interfaces.
C'est une sorte de classe qui ne contient que des définitions de méthodes qui seront définies dans chaque classe qui l'implémente.

8O
Code:

1 2 3 4 5 class Article { ... var $category; var $id_category; }
Il y a quelque chose qui me chagrine dans ton code... pourquoi ces deux propriétés et surtout pourquoi id_... ???

Partons des postulats suivants :
1. Un article appartient à une catégorie
2. Une catégorie contient plusieurs articles

Nous avons donc, dans une approche pur-objet une solution (parmis d'autres) pourrait être la suivante :
(pseudo code)
Code:

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 class Article { int $id; string $title; date $date; string $author; string $content; Category $category; } class ArticleManager { function addArticle () {} function removeArticle () {} function updateArticle () {} function getArticleById () {} } class Category { int $id; string $title; Article[] $articles; function getArticles() {} } class CategoryManager { function addCategory () {} function removeCategory () {} function updateCategory () {} function getCategoryById () {} }
Ici la responsabilité de retourner les articles appartenant à une catégorie est donnée à... la catégorie elle-même. Ce qui parait logique dans un contexte,pour une application, mais pas forcément dans un(e) autre...

Il y a un principe qu'il faut retenir en OO :

Citation:

C'est celui qui sait qui fait

.

23/12/2005, 13h11
Kioob

Pendant qu'on y est, un truc qui m'a toujours gèné dans ce genre de cas :
Admettons que j'ai une requete qui me retourne d'un seul coup la liste de tous les articles d'une catégorie, ainsi que tous les champs utiles de la table... ce qui correspond à 90% des propriétés de mes articles.

Comment vous gèrez ça ?

Je vois plusieurs méthodes, et aucune ne me plait vraiment :

Version "orientée objet, mais nawak coté SQL" :
1) dans mon SELECT je ne prend que les ID des articles, et j'instancie un article pour chaque ID
2) chaque instance d'article refait un joli SELECT pour aller chercher les infos manquantes

Version "optimisée SQL, mais pas très propre coté objet" :
1) je fais mon SELECT qui recupères presque toutes les propriétés, j'instancie un article pour chaque ID
2) pour chaque instance je "recopie" certains des champs récupérés via le SELECT (beurk)
3) chaque instance d'article refera un éventuel SELECT (à la demande), si des informations sont manquantes

Ou autre méthode ? :?

Avant tout j'aimerais préciser que mes articles ne sont pas des produits, mais des articles écrits.

Citation:

Envoyé par ePoX

Oui effectivement on pourrais faire une classe pour obtenir les articles + commentaires indépendamment d'une classe qui ne récupère pas les commentaires.
Sauf que si l'on va au bout de cela on risque d'avoir au final plein de classes dans tout les sens.
Et je craint que l'on s'y perde plus qu'autre chose.

Oui en effet c'est bien ce que je pensais.

Citation:

Envoyé par ePoX

J'aurai plutot envie de dire que le nbre de commentaires est une propriété de ArticleLight. Et que les commentaires en eux mêmes sont une propriétés de Article.

Euhh c'est ce que j'ai dis je crois. Mais peut-être l'ai-je dit d'une façon un peu complexe.

Citation:

Envoyé par ePoX

Mais bon prends cela avec précaution parce qu je suis un peu dérouté par ta conception et je n'arrive pas à voir comment cela peut évoluer avec plus de fonctionnalités...

Ma conception vient en fait de Mr N. qui m'avait orienté vert un modèle similaire pour une gestion de News.

Citation:

Envoyé par siddh

effectivement tu peux pour tes listes n'avoir qu une classe "light" car si tu as beacoup d'articles, ca evitera de surcharger la mémoire.

C'est bien le but, car le contenu des articles sera quelque chose d'assez gros en général, donc il vaut mieux éviter de les récupérer quand il n'y en a pas besoin.

Citation:

Envoyé par siddh

Par contre, peut etre qu'un simple tableau associatif ferais l'affaire ?

Surtout si tu n'y met pas de méthodes.
Ca sert pas a grand chose de créer des objets pour en créer, il faut qu'il y ai une vraie utilité.

Selon moi un article est une entitée à part entière avec une structure bien définie. Donc certes une classe n'est peut-être pas ce qu'il y a de plus approprié, mais je ne crois pas qu'il existe un moyen de créer une pure structure en php4.
Je pourrais bien sûr passer par un tableau associatif, mais je ne trouve pas très propre de ne pas avoir déclaré clairement le type de structure que retournent les méthodes de ma classe.

Mr N. > en effet, id_category n'a peut-être pas sa place ici.
En fait je crois que je me suis laissé piéger par le fait que cette fois-ci je gère les catégories directement en php et non via la bdd.
Mais si Category est une classe, je devrais aussi avoir une classe Author (et le AuthorManager qui va avec) qui pourrait par exemple renoyer la liste des articles d'un certain auteur.

Donc finalement, je crois que je vais faire quelque chose comme ça :
Code:

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 // Structure qui représente un commentaire class Comment { int $id; string $author; date $date; string $content; } // Structure qui représente un article léger class ArticleLight { int $id; string $title; date $date; string $author; string $category; int $nbComment; } // Structure qui représente un article complet class Article extends ArticleLight { string $content; Comment[] $comments; } // Classe de gestion de tout ce petit monde class ArticleManager { function addArticle () {} function removeArticle () {} function updateArticle () {} function getArticleById () {} function getArticleListByCategory () {} function getArticleListByAuthor () {} }
Est-ce-que c'est bon ou alors il y a encore des choses à revoir ?

23/12/2005, 15h22
Mr N.

Comme quoi tout dépend du contexte...
Tu peux très bien gérer la catégorie comme un type concret, ou primitif (chaine de caractères) et donc une simple colonne varchar de ta table article. Seulement tu vas vite avoir des problèmes quand à l'intégrité de tes données. Quid des fautes de frappes, quid des catégories vident, quid des modifications, ... Bonheur total !

Kioob, je n'ai pas compris l'étape 2 de ta 2° version
23/12/2005, 15h29
Mr N.

Citation:

Envoyé par Celelibi

Citation:

Envoyé par ePoX

Mais bon prends cela avec précaution parce qu je suis un peu dérouté par ta conception et je n'arrive pas à voir comment cela peut évoluer avec plus de fonctionnalités...

Ma conception vient en fait de Mr N. qui m'avait orienté vert un modèle similaire pour une gestion de News.

La direction décline toute responsabilité quant aux erreurs de conception effectuée à partir de ses conseils. :lol:
23/12/2005, 18h15
ePoX

Citation:

Version "optimisée SQL, mais pas très propre coté objet" :
1) je fais mon SELECT qui recupères presque toutes les propriétés, j'instancie un article pour chaque ID
2) pour chaque instance je "recopie" certains des champs récupérés via le SELECT (beurk)
3) chaque instance d'article refera un éventuel SELECT (à la demande), si des informations sont manquantes

Personnellement je préfère cela.
Car certe c'est un peu crade quand on vas assigné les propriétés mais bon...
Dans mon cas bien personnel le client veut que son site dépote :)
Donc je préfère faire un peu crade mais le moins de requetes inutile possible (même si il faut être un sacré bourrin pour ralentir lamp).

Ensuite, il peut y'avoir des solutoins pour palier un peu à cela avec les surcharges de méthodes ect... Mais la php5, comme php4, manque cruellement de syntaxe toutes belle toutes jolie toute claire :/ et au final c'est remplacer du crade par du crade ;( Je veux php 6

Mais bon tout cela reste de la conception, et ce n'est pas la conception qui fait vendre un site...

Citation:

Euhh c'est ce que j'ai dis je crois. Mais peut-être l'ai-je dit d'une façon un peu complexe.

En même temps à cette heure je n'avais plus les idées très clair :)

Citation:

Ma conception vient en fait de Mr N. qui m'avait orienté vert un modèle similaire pour une gestion de News.

Mr.N ? Le puit de science tu veux dire :o

Citation:

La direction décline toute responsabilité quant aux erreurs de conception effectuée à partir de ses conseils.

Lol

bye
23/12/2005, 19h35
Celelibi

Citation:

Envoyé par Mr N.

Comme quoi tout dépend du contexte...
Tu peux très bien gérer la catégorie comme un type concret, ou primitif (chaine de caractères) et donc une simple colonne varchar de ta table article. Seulement tu vas vite avoir des problèmes quand à l'intégrité de tes données. Quid des fautes de frappes, quid des catégories vident, quid des modifications, ... Bonheur total !

En fait dans la BDD je stoque seulement l'id de la catégorie et dnas la classe ArticleManager j'ai deux tableaux associatifs pour faire la conversion id <-> nom de catégorie.
Comme les catégories vont rester à peu près figées il n'a pas été prévu de pouvoir ajouter/supprimer des catégories. Lors de l'ajout d'un article je vérifie si la catégorie existe bien, dans le cas contraire c'est un cas d'erreur.
24/12/2005, 02h06
Celelibi

Arg...

En fait je viens de me rendre compte qu'en fait ma dernière solution n'est pas faisable.
En fait les commentaires sont très liés à la classe Membre qui gère les membres inscrits car eux seul auront le droit de laisser des commentaires.
Et j'aimerais que la classe ArticleManager soit réutilisable dans un contexte totalement différent.
Donc articleManager ne doit pas gérer les commentaires liés aux articles.

Et là, euhh je sais plus comment faire.

Une idée les génies de la POO ? :)
24/12/2005, 11h13
Mr N.
c'est difficile de donnée une solution hors du contexte. a priori je ferais comme ça :
Code:

1 2 3 CommentedArticle extends Article CommentedAricleManager extends ArticleManager
Tu peux aussi te dire qu'un article sans commentaires est un article avec 0 commentaire, à toi de faire l'interface en fonction (ne pas afficher le nombre de commentaires, ne pas propser de commentaires...
Code:

1 2 3 4 5 6 7 8 class Article { var $id; var $title; ... var $allow_comments ... }