Bonne conception OO

Version imprimable

Bonne conception OO

Bonjour,

J'essaye de refactoriser mon code pour qu'il soit un peu plus pro.
N'étant pas du métier, j'ai du mal à choisir les bons patterns pour la conception de mon appli.
Je trouve que mon appli est fortement couplé et donc difficille pour la maintenance et futures évolutions.

Par exemple :
J'ai une classe "ZOO" qui contient une liste de "Secteur".
Ma classe "Secteur" contient une liste de "Cage".
Ma classe Cage contient une liste d' "Animal"

Zoo.java

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
 
public abstract class Zoo {
 
	private List<Secteur> 					secteurs        = new ArrayList<Secteur>();
 
	/**
         * Renvoie l'ensemble des secteur
         */
	public List<Station> getListOfStation() {
		return secteurs;
	}
 
	/**
         * Ajoute un secteur à ce zoo
         */
	protected void addSecteurToZoo(Secteur secteur) {		
		int index = this.secteurs.indexOf(station);
		// Si le secteur n'existe pas encore, ajout du nouveau secteur à la liste des secteurs
		if (index == -1) {
			//On ajoute le poste à la liste de poste
			this.secteurs.add(secteur);
		} else {
			secteur = this.secteurs.get(index);
		} 
	}
}

Secteur.java

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
42
43
44
45
46
47
48
49
50
 
public class Secteur{
 
	private String 								secteurName;//Nom du secteur
	private List<Cage>						cages;//Liste des cages
 
	/**
         * Création d'un secteur
         */
	public Station(String name) {
		this.secteurName = name;
		this.cages = new ArrayList<Cage>();
	}
 
	/**
         * Renvoie le nom du secteur
         */
	public String getSecteurName() {
		return stationName;
	}
 
	/**
         * Modifie le nom du secteur
         */
	public void setSecteurName(String secteurName) {
		this.secteurName = secteurName;
	}
 
	/**
         * Renvoie l'ensemble des cages
         */
	public List<Cage> getCages() {
		return cages;
	}
 
	/**
         * Ajoute une cage à ce secteur
         */
	public void addCageToSecteur(Cage cage) {
		int index = this.cages.indexOf(cage);
		// Si la cage n'existe pas encore, ajout de la nouvel cage à la liste
		// des cages
		if (index == -1) {
			// On ajoute le cage à la liste de cage
			this.cages.add(cage);
		} else {
			cage = this.cages.get(index);
		}
	}
}

La classe "Cage" et "Animal" sont presque identiques à "Secteur"

Pour sérialiser / déserialiser mon zoo, j'utilise JDOM. J'ai donc crée deux classe qui étendent de Zoo. XmlReader et XmlWriter

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
 
public class XmlReader extends Zoo{
 
	private Document document;
	private Element racine;
	/**
         * Création du lecteur de fichier XML
         */
	public XmlReader(){
		// On crée une instance de SAXBuilder
		SAXBuilder sxb = new SAXBuilder();
		try {
			// On crée un nouveau document JDOM avec en argument le fichier XML
			document = sxb.build(new File("Zoo.xml"));
			// Le parsing est terminé
		} catch (Exception e) {
			e.printStackTrace();
		}
 
		// On initialise un nouvel élément racine avec l'élément racine du
		// document.
		racine = document.getRootElement();
		//On parcours les différents noeuds de l'arbre
		readSecteur();		
	}
 
	public StationExplorer getStationExplorer(){
		return this;
	}
 
	/**
         * Permet de lire les enfants "secteur" du zoo
         */
	@SuppressWarnings("unchecked")
	private void readSecteur() {
		// On crée une List contenant tous les noeuds "secteur" de l'Element racine
		List<Element> listOfSecteur = racine.getChildren("secteur");
		for(Element element : listOfSecteur){
			//On crée un secteur avec son nom comme attribue
			Secteur secteur = new Secteur(element.getAttributeValue("name"));
			//On ajoute le secteur au zoo
			addSecteurToZoo(secteur);
			//On lit les autres noeuds enfants (cage)
			readCage(secteur,element);
 
		}			
	}
 
	/**
         * Permet de lire les enfants "cage" du secteur
         */
	@SuppressWarnings("unchecked")
	private void readCage(Secteur secteur,Element elementSecteur) {
		// On crée une List contenant tous les noeuds "cage" de l'Element "secteur"
		List<Element> listOfCage = elementSecteur.getChildren("cage");
		for(Element element : listOfCage){
			//On crée un départ avec son nom comme attribue
			Cage cage = new Cage(element.getAttributeValue("name"));
			// On ajoute la cage à son secteur
			secteur.addCageToSecteur(cage);
			//On lit les autres noeuds enfants (animal)
			readAnimal(cage,element);
		}			
	}
 
	/**
         * Permet de lire les enfants "equipement" du départ
         * @param departure
         * @param elementDeparture
         */
	@SuppressWarnings("unchecked")
	private void readAnimal(Cage cage,Element elementCage) {
		// On crée une List contenant tous les noeuds "animal" de l'Element "cage"
		List<Element> listOfAnimal = elementCage.getChildren("animal");
		for(Element element : listOfAnimal){
			//On crée un animal avec son nom
			Animal animal = new Animal(element.getAttributeValue("name"));
			//On ajoute l'équipement à son départ
			cage.addAnimalToCage(animal);			
		}			
	}
}

La classe XmlWriter est presque identique à XmlReader sauf comme son nom l'indique, elle permet d'écrire dans un fichier xml

Avec ce petit exemple, pouvez-vous m'aider à mieux concevoir mon appli pour qu'elle soit plus souple, plus pro !
Mon problème si je veux ajouter par exemple, une nouvelle variable d'instance, dans une de mes classes Zoo, Secteur, Cage ou Animal, je dois modifier aussi Xml Reader et XmlWriter avec toutes les erreurs possibles.

D'avance merci pour vos conseils :)

30/06/2009, 18h20
djo.mos

Salut,
Un truc déjà : pourquoi faire Hériter Xml(Reader|Writer) de tes objets Zoo et co ? Je trouve pas ça très propre.
Dans ton cas, ces objets servent à stocker les données, pas à avoir un comportement, qui plus est est spécifique à la persistence (xml dans ton cas).

Une approche beacoup plus propre amha serait de créer des classes Codec : ZooXmlCodec, SecteurXmlCodec, etc. avec des méthodes encode/decode.

Pour un maximum de réutilisabilité, je ferais en sorte que encode prend l'objet et rend un Element (xml), tandis que decode prend un Element et rend l'objet.

De cette façon, tu peux utiliser un codec dans un autre codec (ZooXmlCodec puet utiliser SecteurXmlCodec pour sérialiser ses fils dans le meme DOM).
30/06/2009, 18h45
tchize_

pour la lecture / écriture en xml, ut peux aussi t'orienter vers des outils tout fait comme xstream, que tu n'aura plus qu'à configurer pour avoir le format voulu.
01/07/2009, 18h19
pingoui

Salut,

Merci pour vos conseils.
Pour Xstream, j'ai été fortement séduit par la simplicité de cette API. Mais je me suis freiné lorsque j'ai utilisé une API du même type (Castor).

Je programme une application RCP et apparemment, il y a des problèmes de compatibilité entre le rongeur et eclipse. J'ai fait (peut être à tord) le rapprochement avec XStream.

De plus après la sérialisation/désérialisation, je cherche, modifier plusieurs noeuds de mon arbre. Je me demande si cela va pas me bloquer plus tard.:?
Dois-je réécrire complètement l'arbre dès que je modifie un objet?

Si XStream correspond à mes besoins, je suis plus que partant pour l'adopter :D

D'avance merci
01/07/2009, 20h50
tchize_

avec xstream tu devra effactivement refaire le rendu lorsque tu modifie un élément. Il ne fait pas de lien "arbre d'objet" <-> "arbre dom", au contraire, il prend un arbre d'objet et fait un rendu xml et vis versa (en fait il est pas limité au xml, y a un rendu json aussi si ma mémoire est bonne).

Si tu veux avoir un arbre dom dynamique en // à ton arbre d'objet va falloir y aller à la mano, mais je suis pas sur que ce soit utile de devoir garder les deux en mémoire.

Salut,

J'ai opté pour avoir un arbre dynamique et donc faire cela à la main ;)

J'ai donc créer une Classe XmlCodec qui permet d'écire et parser les xml

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
 
public class XmlCodec {
 
	private static Document document;
	private static Element racine;
 
	public static  void readXml(Zoo zoo){
		// On crée une instance de SAXBuilder
		SAXBuilder sxb = new SAXBuilder();
		try {
			// On crée un nouveau document JDOM avec en argument le fichier XML
			document = sxb.build(new File("Zoo.xml"));
			// Le parsing est terminé
		} catch (Exception e) {
			e.printStackTrace();
		}
 
		// On initialise un nouvel élément racine avec l'élément racine du
		// document.
		racine = document.getRootElement();
		//On parcours les différents noeuds de l'arbre
		SecteurCodec.readSecteur(zoo,racine);
	}
 
 
	public static void writeXml(Zoo zoo){
		racine = new Element("explorer");
		SecteurCodec.writeSecteur(zoo,racine);
		document = new Document(racine);
 
		try {
			// On utilise ici un affichage classique avec getPrettyFormat()
			XMLOutputter sortie = new XMLOutputter(Format.getPrettyFormat());
			// Sérialisation
			sortie.output(document, new FileOutputStream("ZooBis.xml"));
		} catch (java.io.IOException e) {
		}
	}
 
}

Ensuite, j'ai crée une classe par objet à sérialiser (Secteur, Cage, Animal)
SecteurCodec.java

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class SecteurCodec {
 
 
	/**
         * Permet d'écrire les enfants "secteur" du zoo
         */
	protected static void writeSecteur(Zoo zoo,Element racine){
///// ici le code pour écrire les secteurs
			CageCodec.writeCage(secteur,secteurElement);
 
///// le reste du code
	}
}

J'ai donc maintenant CageCodec, AnimalCodec sur le même principe que SecteurCodec.

Est-ce déjà plus propre ? plus pro

Merci pour vos conseils

03/07/2009, 21h11
Tommy31

Citation:

Envoyé par pingoui

J'ai donc maintenant CageCodec, AnimalCodec sur le même principe que SecteurCodec.

Est-ce déjà plus propre ? plus pro

Merci pour vos conseils

Supprime les statics dans la classe XmlCodec. Si tu dois créer un ensemble de convertisseurs, définis une interface (paramétrée) qu'ils implémenteront.
04/07/2009, 08h43
pingoui

Salut
Pour faire apple à readXml et writeXml, il faut que ces méthodes soit static ? En plus, je n'ai pas besoin d'intacier cette classe.c'est plus une classe utilitaire.

Que veut tu dire par interface "paramétrée" ?
Je crée par exemple une interface Codec avec les méthodes read et write mais je ne vois pas comment faire le lien entre les différents codec vu que c'est un arbre, il faut attaquer les codec dans un certain ordre

D'avance merci
04/07/2009, 09h32
Tommy31

Citation:

Envoyé par pingoui

Salut
Pour faire apple à readXml et writeXml, il faut que ces méthodes soit static ? En plus, je n'ai pas besoin d'intacier cette classe.c'est plus une classe utilitaire.

Sauf qu'elle dispose d'un état (document et racine). Ce qui devient problématique si la classe est partagée. En outre, tu t'interdis tout polymorphisme.

Citation:

Envoyé par pingoui

Que veut tu dire par interface "paramétrée" ?
Je crée par exemple une interface Codec avec les méthodes read et write mais je ne vois pas comment faire le lien entre les différents codec vu que c'est un arbre, il faut attaquer les codec dans un certain ordre

Tu définis une interface qui déclare les 2 méthodes read et write avec un paramètre générique. Chaque code devra alors l'implémenter. Ce ne change rien à la logique de ton code, c'est juste un travail sur le typage.

Cela dit, ce qui me gêne dans ton implémentation des codecs, c'est qu'ils s'appellent les uns les autres selon la logique des données à sérialiser. Une approche contournant ce problème serait d'utiliser le pattern visitor.

Citation:

Envoyé par Tommy31

Cela dit, ce qui me gêne dans ton implémentation des codecs, c'est qu'ils s'appellent les uns les autres selon la logique des données à sérialiser. Une approche contournant ce problème serait d'utiliser le pattern visitor.

Moi aussi ça me gêne beaucoup sauf que j'ai du mal à concevoir quelque chose de propre. J'ai regardé le pattern Visitor mais il est pas trop parlant pour moi. j'arrive pas trop à comprendre sont fonctionnement et son utilité :oops:

J'ai regardé aussi le pattern Patron mais je ne suis pas sur qu'il correspond à mon problème :?

Désormais ZooCodec, SecteurCodec, CageCodec et AnimalCodec implémentent l'interface Codec
Code:

1 2 3 4 5 public interface Codec { public void read(Object object,Element element); public void write(Object object,Element element); }
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 public class CageCodec implements Codec{ private AnimalCodec animalCodec = new AnimalCodec(); /** * Permet de lire les enfants "cages" du secteur */ @SuppressWarnings("unchecked") public void read(Object object,Element elementSecteur) { Secteur secteur = (Secteur)object; // On crée une List contenant tous les noeuds "cage" de l'Element "secteur" List<Element> listOfCages = elementEquipment.getChildren("cage"); for(Element element : listOfCage){ //On crée une cage avec son nom comme attribues Cage cage = new Cage(element.getAttributeValue("name")); //On ajoute la cage à son secteur secteur.addCageToSecteur(cage); //On lit les autres noeuds enfants (animal) animalCodec.read(cage,element); } } public void write(Object object,Element secteurElement){ Secteur secteur = (Secteur)object; for(Cage cage :equipment.getListOfCage()){ Element cageElement = new Element("cage"); Attribute cageName = new Attribute("name",cage.getCageName()); cageElement.setAttribute(cageName); animalCodec.write(cage,cageElement); secteurElement.addContent(cageElement); } } }

04/07/2009, 19h17
Tommy31
Tu as un jdk égal ou supérieur à 1.5 ? Si oui, exploite les generics pour renforcer le typage :
Code:

1 2 3 4 5 public interface Codec<T> { public void read(T object,Element element); public void write(T object,Element element); }
et :
Code:

1 2 3 4 public class CageCodec implements Codec<Cage> { ... }
Citation:

Envoyé par pingoui

Moi aussi ça me gêne beaucoup sauf que j'ai du mal à concevoir quelque chose de propre. J'ai regardé le pattern Visitor mais il est pas trop parlant pour moi. j'arrive pas trop à comprendre sont fonctionnement et son utilité :oops:

Difficile à expliquer en quelques mots. Pour ton problème, il faut rendre toutes tes classes métiers (Zoo, Cage, Secteur...) visitables. Pour cela il faut définir une méthode qui accepte un visiteur en argument.
Code:

1 2 3 4 5 6 7 8 9 public class Zoo { public void accept( Visitor v) { v.visit(this); for( Secteur secteur : secteurs ) { secteur.accept( v ); } } }
Ensuite, l'implémentation du visiteur consiste à coder les méthodes de visite qui prennent en argument chacun des types visitables, de la même façon que les codecs le faisaient. Mais ici, ils se retrouvent tous codés dans la même classe :
Code:

1 2 3 4 5 6 7 public class XmlVisitor implements Visitor { public void visit( Zoo zoo) {} public void visit( Secteur secteur) {} public void visit( Cage cage) {} public Document getDocument() {} }
Tu vois le principe ?
Note que ce n'est pas nécessairement un meilleur choix que l'autre. Il y a des avantages et des inconvénients, et le pattern visitor a ses adorateurs et détracteurs. Personnellement, je l'aime bien.
04/07/2009, 20h24
pingoui
Merci beaucoup pour ton aide ! :D
Citation:
Envoyé par Tommy31

Code:

1 2 3 4 public class CageCodec implements Codec<Cage> { ... }
Vu que mes classes sont "imbriqués", pour insérer la cage dans le bon secteur, j'utilise Secteur en paramétre
Code:

1 2 3 4 5 6 public class CageCodec implements Codec<Secteur> { public void read(Secteur secteur,Element elementSecteur) { .... } }
J'espère ne pas faire d'erreur de conception :oops:
Citation:
Ensuite, l'implémentation du visiteur consiste à coder les méthodes de visite qui prennent en argument chacun des types visitables, de la même façon que les codecs le faisaient. Mais ici, ils se retrouvent tous codés dans la même classe :

Code:

1 2 3 4 5 6 7 public class XmlVisitor implements Visitor { public void visit( Zoo zoo) {} public void visit( Secteur secteur) {} public void visit( Cage cage) {} public Document getDocument() {} }

Tu vois le principe ?
Désolé, mais j'ai vraiment du mal avec ce pattern :oops: Malgré tes explications et ce que j'ai lu sur la toile, j'ai du mal à comprendre la finalité :oops:
Je me suis re-plongé dans mon livre de pattern mais celui-ci l'explique très rapidement et c'est loin d'être explicite:?