Architecture de classe pour POO [Résolu]

[LegGohan]

Bonjour à tous,
j'ai besoin de votre aide car je manque d'experience en POO en PHP et je souhaiterais avoir un exemple d'architecture le mieux adapté à mon programme.

J'ai une application de gestion documentaire avec des bases de données. Je vais vous expliquer l'architecture de ma base de donnée et ensuite mon problème concernant l'architecture de mes classes.

J'ai une table documentation qui contient plusieurs informations comme le nom du doc, sa date, etc...
J'ai ensuite une table emplacement_document car celui ci peut appartenir à plusieurs rubriques et sous rubriques. Exemple un document sur l'environnement et la politique ou un document uniquement sur l'espace.
J'ai aussi une table rubriquequi contient des infos sur ces mêmes rubriques.
Et une table sous rubriques
=> Il y a donc une relation many to many entre mes tables documentation et rubrique / sous rubriques.

De plus pour chaque document je peux avoir 1 ou plusieurs auteurs. Relation one to many.

Voici donc l'architecture de ma base de donnée. J'ai suivi de nombreux exemple de POO en PHP mais je n'arrive pas à effectuer une architecture de mes classes. Ce sont les attributs auteurs et rubriques qui me posent problèmes. Dois je faire une classe document qui contient tous ou séparer en plusieurs classes ???

On explique souvent la POO avec des voitures et il y a des bleu, rouge, grande, petite, etc...
Je crois que je pourrais simplement exposer mon problème en demandant comment rajouter dans ma classe un attribut conducteur sachant qu'il peut y en avoir un ou plusieurs ???

Merci d'avance de votre aide

[kalimukti]

Bonjour,
je reprends ta structure de base:

Envoyé par LegGohan

De plus pour chaque document je peux avoir 1 ou plusieurs auteurs. Relation one to many.

ça donne une relation many to many, plutôt nan ? (1 document pour plusieurs auteurs, 1 auteur pour plusieurs docs)

ensuite, tu sembles avoir une relation réflexive 1tomany dans ta table rubriques: une relation genre APPARTENIR:
1 rubrique n'appartient à aucune rubrique ==> rubrique
1 rubrique appartient à une rubrique ==> sous-rubrique
(ça donne ta clé primaire de rubrique qui s' "exporte" dans ta table rubrique, ce qui donne un champ possiblement NULL, genre "appartient")...

pour ce qui est un ou plusieurs auteurs: pourquoi ne pas gérer dans ton BO (objet métier) la propriété $auteur comme un tableau de valeur ?
(au pire avec une méthode addAuteur ($aut) qui te rajoute un auteur ($aut) à la collection $auteur[] et retourne le tableau...)
si tu veux aller un peu plus loin (et que l'anglais ne te gène pas), tu peux aller voir du côté du pattern iterator

[grunk]

A mon avis la table sous-rubrique est discutable. Il y'a des solutions plus adaptée pour ce genre de chose notamment la représentation intervallaire qui permet une profondeur infinie de sous rubrique.

Pour les auteurs la solution de kalimukti est bonne.
Une classe auteur et un paramètre dans ta classe document qui sera un tableau d'auteur.
Si on veux faire les truc bien on pourrait changer le tableau par un SPLObjectStorage

[kalimukti]

Envoyé par grunk

A mon avis la table sous-rubrique est discutable. Il y'a des solutions plus adaptée pour ce genre de chose notamment la représentation intervallaire qui permet une profondeur infinie de sous rubrique.
[...]
Si on veux faire les truc bien on pourrait changer le tableau par un SPLObjectStorage

Je connaissais ni l'un ni l'autre et ça m'a l'air intéressant. Surtout la représentation intervallaire, m'a l'air puissant ch'truc là.
Merci pour les infos grunk

[LegGohan]

Merci pour vos réponses, en fait j'ai essayé de simplifier au max mes tables pour expliquer le plus rapidement et simplement mon problème. Du coup vous trouvez des erreurs de BDD qui sont du à mon manque d'explication. J'en suis désolé.

Envoyé par kalimukti

Bonjour,
je reprends ta structure de base:


ça donne une relation many to many, plutôt nan ? (1 document pour plusieurs auteurs, 1 auteur pour plusieurs docs)

Effectivement ca devrait être une relation many to many. Mais les auteurs etant dans une BDD différente, je n'ai pas de lien entre la base de donnée des auteurs de document et la base de donnée de tous les utilisateurs. C'est pour cela que j'ai une relation one to many. Je selectionne les infos dont j'ai besoin et je les copies dans ma table auteurs

Envoyé par kalimukti

ensuite, tu sembles avoir une relation réflexive 1tomany dans ta table rubriques: une relation genre APPARTENIR:
1 rubrique n'appartient à aucune rubrique ==> rubrique
1 rubrique appartient à une rubrique ==> sous-rubrique
(ça donne ta clé primaire de rubrique qui s' "exporte" dans ta table rubrique, ce qui donne un champ possiblement NULL, genre "appartient")...

Concernant cette partie, disons pour simplifier que je n'ai qu'une relation many to many entre mon document et les rubriques. Un document peut avoir plusieurs rubriques et une rubrique peut apprtenir à plusieurs documents. Exemple un document sur l'environnement et la politique ou un document uniquement sur l'espace.

Envoyé par kalimukti

pour ce qui est un ou plusieurs auteurs: pourquoi ne pas gérer dans ton BO (objet métier) la propriété $auteur comme un tableau de valeur ?
(au pire avec une méthode addAuteur ($aut) qui te rajoute un auteur ($aut) à la collection $auteur[] et retourne le tableau...)
si tu veux aller un peu plus loin (et que l'anglais ne te gène pas), tu peux aller voir du côté du pattern iterator

Merci pour cette réponse. En fait la table auteur a plusieurs infos comme le nom, prénom, etc....
Du coup si je décide d'avoir une architecture comme ceci :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
class Document {
    protected $id;
    protected $titre;
    protected $edition;
    protected $key_word;
    protected $resume;
    protected $date;
 
    protected $auteur;
    protected $rubriques;
}
?>

Je fais alors un tableau de tableau pour $auteur ?? J'avais essayé ceci mais la gestion des attributs est assez coton .

J'avais aussi penser à définir un nombre max d'auteur avec $auteur1 jusqu'à $auteur8.

J’espère vous avoir éclairer dans mes explications tordu mais si on prend le cas de l'auteur c'est précisément ces données qui me posent problème.

Merci de votre attention

[grunk]

Je fais alors un tableau de tableau pour $auteur ?? J'avais essayé ceci mais la gestion des attributs est assez coton .

J'avais aussi penser à définir un nombre max d'auteur avec $auteur1 jusqu'à $auteur8.

J’espère vous avoir éclairer dans mes explications tordu mais si on prend le cas de l'auteur c'est précisément ces données qui me posent problème.

Un tableau d'objet plutôt. Tu devrais (dans le meilleur des mondes) avoir une représentation de tes auteurs via une classe Auteur. Ce qui donnerais avec un tableau :

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
34
35
36
37
38
39
40
41
class Auteur
{
	private $nom;
	private $prenom;
}
 
class Document 
{
	protected $id;
	protected $titre;
	protected $edition;
	protected $key_word;
	protected $resume;
	protected $date;
 
	protected $auteur;
	protected $rubriques;
 
	public setAuteur(Auteur $auteur)
	{
		if(count($this->auteur) < 8)
			array_push($this->auteur,$auteur);
		else
			throw new TooMuchAuteurException;
	}
 
	public getAuteurs()
	{
		return $this->auteur;
	}
}
 
$auteur = new Auteur('Foo','Bar');
try {
	$document->setAuteur($auteur);
} catch (TooMuchAuteurException $e) {
	echo 'ce document ne supporte pas plus d\'auteur';
}
 
$auteurs = $document->getAuteurs();
echo $auteurs[0]->getNom();

Après rien de bien sorcier, suffit d'itérer sur le tabelau d'auteur pour en supprimer un ou récupérer ses infos.

SPLObjectStorage n'est pas du tout une obligation , c'est juste pour faire les choses bien jusqu'au bout

[kalimukti]

LegGohan,

Envoyé par LegGohan

Concernant cette partie, disons pour simplifier que je n'ai qu'une relation many to many entre mon document et les rubriques. Un document peut avoir plusieurs rubriques et une rubrique peut apprtenir à plusieurs documents. Exemple un document sur l'environnement et la politique ou un document uniquement sur l'espace.

Je vois... mais tu as en fait 3 relations là:
entre docs et rubrique (n-n)
entre docs et sous-rubriques (n-n)
entre rubriques et sous-rubriques (cf représentation intervallaire de grunk)
je vois pas trop comment tu peux en faire l'économie...

Je fais alors un tableau de tableau pour $auteur ?? J'avais essayé ceci mais la gestion des attributs est assez coton

enfin, un objet qui a comme attribut un tableau d'objets... mais le principe est là oui..
tu as accès à tes auteurs avec un truc du style:

Code :

$doc->auteur[1]->nom

si tu veux gérer le nombre d'auteurs max ou les indices de ton tableaux d'auteurs, tout ça se passera dans ta méthode addAuteurs de ta classe Document...

[LegGohan]

Mille merci à vous deux, j'ai pu ainsi établir l'architecture de ma classe document avec tous les tableaux d'objet dont j'ai besoin.
Pour le moment je ne fais qu'instancié un objet document et celui ci récupère tout ce dont j'ai besoin.

Merci grunk pour ton exemple très claire et qui m'a bien aidé, notamment comment récupérer le tableau d'objet et en afficher le contenu

$auteurs = $document->getAuteurs();
echo $auteurs[0]->getNom();

Du coup avec un foreach, je lis tous le contenu

Je reviendrais peut être vers vous si j'ai des problèmes dans la création ou modification d'attribut ou tableau d'objet mais je pense avoir une bonne base de travail bien Architecturée

Encore merci