Discussion :

[snyfir]

Bonjour,

J'ai trois classe avec chacune leur table mysql : catégorie, article, page.
Les catégorie contiennent des articles, et les articles contient des pages.

Chacune de mes trois classes sont indépendantes. (je programme en poo).
Je voulais savoir si je doit les rendre moin indépendante pour une meilleur approche et une meilleur fonctionnalité, ou les laisser indépendante. Avec l'heritage, l'imbrication de classe, le polymorphisme, les interfaces.. Je ne c'est plus ou donner de la tête. Vos conseil serais les bienvenue. Et merci d'avance pour vos réponsses.

BDD Categorie :


BDD Article:


BDD page:


Structure de ma classe page :

[Tsilefy]

Bonsoir,

D'abord, je verrais plus la relation entre tes trois tables matérialisées par des clés étrangères. Cette relation sera ensuite transposée dans les classes.

Une classe n'est pas un concept abstrait, elle doit réfleter tes objets. Si tes objets ont des relations avec d'autres, il est normal que cela soit transcrit. Cela te permettra de les manipuler plus facilement. En fait, je ne vois pas comment tu pourrais faire autrement, à moins de compliquer les choses.
Donc, par ex:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class Article {
  private $idCategory; //foreign key dans la base
 
  public function getIdCategory() {
      return $this->idCategory;
      }
  public function setIdCategory($idCategory) {
      $this->idCategory = $idCategory;
     }
}

[snyfir]

Bonsoir,

D'abord, je verrais plus la relation entre tes trois tables matérialisées par des clés étrangères. Cette relation sera ensuite transposée dans les classes.

Une classe n'est pas un concept abstrait, elle doit réfleter tes objets. Si tes objets ont des relations avec d'autres, il est normal que cela soit transcrit. Cela te permettra de les manipuler plus facilement. En fait, je ne vois pas comment tu pourrais faire autrement, à moins de compliquer les choses.
Donc, par ex:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class Article {
  private $idCategory; //foreign key dans la base
 
  public function getIdCategory() {
      return $this->idCategory;
      }
  public function setIdCategory($idCategory) {
      $this->idCategory = $idCategory;
     }
}

Merci pour votre réponse.
Pouriez vous être plus explicite, car je n'est pas bien compris.

[Tsilefy]

Bonsoir,

Ton application manipule 3 types d'objets : catégorie, article et page.
L'objectif est de parvenir à une représentation de ces trois types d'objets qui soit à la fois la plus conforme possible à la réalité et la plus facile à manipuler possible.
Voyons les relations entre les types d'objets (i.e. la table et la classe), par ex entre article et catégorie:
- 1 article appartient à une catégorie (on va simplifier, et supposer qu'il n'appartient qu'à une seule et unique catégorie)
- une catégorie contient un ou plusieurs articles.
Dans la conception de tes tables, cela suppose que chaque table article garde une référence à la catégorie à laquelle il appartient. C'est idCategorie dans ta table. Mais pour marquer cette relation, pour la renforcer, il faut imposer des contraintes : chaque article doit appartenir à une catégorie (même si cette catégorie est 'non classé'). idCategorie doit donc être définie comme étant une foreign key (clé étrangère), et référencer directement une catégorie de la table Categorie.
Les clés étrangères ne sont possible que si ta table est en innoDB. Regarde la doc pour plus de détails sur les clés étrangères. Ça t'asure par exemple qu'aucune catégorie n'est malencontreusement effacée alors qu'elle contient encore des articles, ou à contrario que la suppression d'une catégorie détruit tous les articles liés, ou qu'aucun article sans Catégorie ne soit écrit, etc...

Du côté de la représentation objet, la relation article->catégorie se manifeste par le fait que chaque objet article détient une référence sur sa catégorie:

Code :

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

private $idCategorie;

, et tu accède à la catégorie de la page à partir de cet idCatégorie par le traditionnel getter

Code :

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

public function getIdCategory()

Tu te serviras ensuite de l'ID ainsi retourné pour effectuer une recherche sur la catégorie correspondante dans la table.

L'objectif est donc qu'à partir d'un article, tu puisses retrouver la catégorie à laquelle il appartient, modifier cette catégorie voire plus tard ajouter une nouvelle catégorie. Donc, tu ne peux pas créer une classe article sans référence à sa catégorie, c'est-à-dire complètement autonome.

Je suppose que c'est ce que tu entends par indépendance : isoler totalement chaque classe et ne pas les pourvoir de références à d'autres objets. Dans ton cas, ce n'est pas , à mon avis, recommandé.

[snyfir]

Je suppose que c'est ce que tu entends par indépendance : isoler totalement chaque classe et ne pas les pourvoir de références à d'autres objets. Dans ton cas, ce n'est pas , à mon avis, recommandé.

Si je fait comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class category
{
   ...
}
 
class item extends category
{
   ...
}
 
class page extends item
{
   ...
}

Ce serait une bonne méthode ?

[Tsilefy]

Si je comprends bien ton modèle, ce n'est pas une bonne approche.

Code :

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

class page extends item

est de l'héritage, c'est à dire une relation (IS A) : page est un item. Or ce n'est pas le cas. Les deux objets ont des objectifs et des fonctionnalités totalement différents. Alors que

Code :

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

1
2
class item {
      private var $item;

est de la composition, une relation (HAS A): item contient une ou plusieurs pages. Ce qui est plutôt le cas ici.

Quoique je tempère ma réponse par le fait que je ne comprends pas exactement ce qu'est item.

L'héritage s'applique plus par exemple si tu as des catégories, et des sous- catégories, et des rubriques, qui tous relèvent d'une même chose : servir de référence à un ensemble d'autres objets (articles, autres rubriques, etc..). Or, ici, l'objet page au moins ne contient pas d'autre objets.

Pour plus de détails sur l'héritage et la composition, voir la partie consacrée sur 'Penser en Java' de Bruce Eckel (Traduction ici ). C'est un livre sur Java, mais les concepts exposés s'appliquent à la POO en général.

Edit : je viens aussi de trouver cet article.