Comment éviter de dupliquer le code commun de deux class ayant une meme interface ?

Version imprimable

Bonjour,

J'ai deux class presque identiques à une méthode près.
Je leur ai donné une interface commune, pour pouvoir les utiliser avec une ArrayList.
Néanmoins il reste du code commun dupliqué.
Peut-on éviter de dupliquer le code commun aux deux class ?

Projet exemple complet

Merci,

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
public class AAA01 implements Iaaa {
	private int zz;
 
	public AAA01(int zz) {
		this.zz = zz;
	}
 
	private void setZz(int zz) {
		this.zz = zz;
	}
 
	private int getZz() {
		return zz;
	}
 
	public  int methodeAA(int x) {
		setZz(getZz() + x);
		return getZz();
	}
 
	public  int methodeBB(int x) {
		setZz(getZz() * x);
		return getZz();
	}
 
	@Override
	public String toString() {
		return String.valueOf(getZz());
	}
 
}

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
public class AAA02 implements Iaaa {
	private int zz;
 
	public AAA02(int zz) {
		this.zz = zz;
	}
 
	private void setZz(int zz) {
		this.zz = zz;
	}
 
	private int getZz() {
		return zz;
	}
 
	public int methodeAA(int x) {
		setZz(getZz() + x + 10);
		return getZz();
	}
 
	public int methodeBB(int x) {
		setZz(getZz() * x);
		return getZz();
	}
 
	@Override
	public String toString() {
		return String.valueOf(getZz());
	}
 
}

Code:

1
2
3
4
5
6
7
public interface Iaaa {
 
	public abstract int methodeAA(int x);
 
	public abstract int methodeBB(int x);
 
}

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
import java.util.ArrayList;
import java.util.List;
 
public class MainTestJava {
 
	/**
         * @param args
         */
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		MainTestJava mainTestJava = new MainTestJava();
 
	}
 
	public MainTestJava() {
		List<Iaaa> aaa = new ArrayList<Iaaa>();
 
		aaa.add(new AAA01(100));
		aaa.add(new AAA01(200));
		aaa.add(new AAA02(100));
		aaa.add(new AAA02(200));
 
		for (Iaaa iaaa : aaa) {
			iaaa.methodeAA(2);
			iaaa.methodeBB(10);
			System.out.println(iaaa.toString());
		}
	}
 
}

12/10/2009, 11h40
fr1man

Tu peux passer par une classe abstraite intermédiaire.

ou tu peux hériter AAA02 de AAA01 en redéfinissant methodAA
Code:

1 2 3 4 5 6 7 public class AAA02 extends AAA01{ //.... public int methodeAA(int x) { //.... return getZz(); }

12/10/2009, 12h55
entreprise38

+1 pour la classe abstraitre, c'est la vision la plus logique.

=> AAA02 de AAA01 ? Si l'héritage entre les deux a un sens, oui, mais ça n'a pas l'air d'être le cas ici.

=> AAA02 et AAA01 héritent d'une classe abstraite ? Les deux validant la même interface et ayant du code en commun : leur trouver un parent commun qui, par la même occasion, validera aussi l'interface, est sans doute la solution. Ce parent n'ayant aucune raison d'être instancié, il remplit les conditions pour être une classe abstraite.
12/10/2009, 13h46
hibour

8O c'est vrai que s'il n'y a pas de relation entre les 2 classes alors l'héritage n'a aucun sens mais bon, s'il y a autant de ressemblance dans le code alors je pense qu'une tel relation existe et un simple héritage ferai l'affaire :mrgreen:

J'ai bien compris ?

Code:

1
2
3
4
5
6
7
8
9
10
 
public interface Iaaa {
 
	public abstract int methodeAA(int x);
 
	public abstract int methodeBB(int x);
 
	public abstract String toString();
 
}

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
 
abstract class AbsAAA implements Iaaa {
	private int zz;
 
	public AbsAAA(int zz) {
		this.zz = zz;
	}
 
	protected void setZz(int zz) {
		this.zz = zz;
	}
 
	protected int getZz() {
		return zz;
	}
 
	public  int methodeBB(int x) {
		setZz(getZz() * x);
		return getZz();
	}
 
	@Override
	public String toString() {
		return String.valueOf(getZz());
	}
 
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
 
public class AAA01 extends AbsAAA{
 
	public AAA01(int zz) {
		super(zz);
		// TODO Auto-generated constructor stub
	}
 
	@Override
	public int methodeAA(int x) {
		setZz(getZz() + x);
		return getZz();
	}
 
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
 
public class AAA02 extends AbsAAA{
 
	public AAA02(int zz) {
		super(zz);
		// TODO Auto-generated constructor stub
	}
 
	@Override
	public int methodeAA(int x) {
		setZz(getZz() + x + 10);
		return getZz();
	}
 
}

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
 
import java.util.ArrayList;
import java.util.List;
 
public class MainTestJava {
 
	/**
         * @param args
         */
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		MainTestJava mainTestJava = new MainTestJava();
 
	}
 
	public MainTestJava() {
		List<Iaaa> aaa = new ArrayList<Iaaa>();
 
		aaa.add(new AAA01(100));
		aaa.add(new AAA01(200));
		aaa.add(new AAA02(100));
		aaa.add(new AAA02(200));
 
		for (Iaaa iaaa : aaa) {
			iaaa.methodeAA(2);
			iaaa.methodeBB(10);
			System.out.println(iaaa.toString());
		}
	}
 
}

J'ai supprimé une classe, et cela semble être toujours bon.
Suis je obligé d'appeler le constructeur dans les class d'implantation ?

Projet complet

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
 
abstract class AbsAAA {
 
	private int zz;
 
	public AbsAAA(int zz) {
		this.zz = zz;
	}
 
	protected void setZz(int zz) {
		this.zz = zz;
	}
 
	protected int getZz() {
		return zz;
	}
 
	abstract int methodeAA(int x);
 
	public  int methodeBB(int x) {
		setZz(getZz() * x);
		return getZz();
	}
 
	@Override
	public String toString() {
		return String.valueOf(getZz());
	}
 
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
 
public class AAA01 extends AbsAAA{
 
	public AAA01(int zz) {
		super(zz);
		// TODO Auto-generated constructor stub
	}
 
	@Override
	public int methodeAA(int x) {
		setZz(getZz() + x);
		return getZz();
	}
 
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
 
public class AAA02 extends AbsAAA{
 
	public AAA02(int zz) {
		super(zz);
		// TODO Auto-generated constructor stub
	}
 
	@Override
	public int methodeAA(int x) {
		setZz(getZz() + x + 10);
		return getZz();
	}
 
}

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
 
import java.util.ArrayList;
import java.util.List;
 
public class MainTestJava {
 
	/**
         * @param args
         */
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		MainTestJava mainTestJava = new MainTestJava();
 
	}
 
	public MainTestJava() {
		List<AbsAAA> aaa = new ArrayList<AbsAAA>();
 
		AAA01 aaa01 = new AAA01(5);
 
		aaa.add(new AAA01(100));
		aaa.add(new AAA01(200));
		aaa.add(new AAA02(100));
		aaa.add(new AAA02(200));
 
		for (AbsAAA iaaa : aaa) {
			iaaa.methodeAA(2);
			iaaa.methodeBB(10);
			System.out.println(iaaa.toString());
		}
	}
 
}

13/10/2009, 09h35
Patriarch24

Citation:

s'il y a autant de ressemblance dans le code alors je pense qu'une tel relation existe et un simple héritage ferai l'affaire

Tu auras droit à cent :sm:
:mrgreen:
+1 pour la classe abstraite, à condition que la relation "est un(e)" soit valide. Sinon, utiliser la composition.
13/10/2009, 15h55
hibour

Citation:

Envoyé par Patriarch24

Tu auras droit à cent :sm:
:mrgreen:
+1 pour la classe abstraite, à condition que la relation "est un(e)" soit valide. Sinon, utiliser la composition.

:mouarf: Ca fait mal :p
Il veut un truc simple pour ne pas dupliquer le code alors l'héritage ferai l'affaire.. Pourquoi se compliquer la vie en créant une classe intermédiaire abstraite ou non qui peut ne plus servir après!
Je dit Héritage :mrgreen:
13/10/2009, 17h41
Patriarch24

Bon ok ce sera 1000 coups :mrgreen:
13/10/2009, 22h12
entreprise38

hibour, certes, "ça marche", mais cela revient à te faire des brochettes avec un lance-flammes plutôt qu'un barbecue 8-)
Soucis : si héritage nous utilisons, que se passera t-il si un jour il veut modifier le comportement de la classe mère ? Bonjour les dégâts.
Le modèle objet vient avec toute une méthodologie qu'il faut respecter pour de bonnes raisons : avoir un code évolutif, maintenable, mais surtout, alors surtout logique.
14/10/2009, 10h20
Pierre8r

Citation:

Envoyé par Patriarch24

Sinon, utiliser la composition.

Bonjour,
Comment coder mon exemple, en utilisant la composition ?

En l'occurrence, après avoir lu le code, c'est même plus simple que ça (pas besoin de composition en réalité) :
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 AAA implements Iaaa { private int zz; private int aa; public AAA01(int zz, int aa) { this.zz = zz; this.aa = aa; } private void setZz(int zz) { this.zz = zz; } private int getZz() { return zz; } public int methodeAA(int x) { setZz(getZz() + x + aa); return getZz(); } public int methodeBB(int x) { setZz(getZz() * x); return getZz(); } @Override public String toString() { return String.valueOf(getZz()); } }
L'instance correspondant à la classe AAA01 prend en paramètre aa = 0, l'autre (AAA02) aa = 10.

14/10/2009, 11h58
Pierre8r

Citation:

En l'occurrence, après avoir lu le code, c'est même plus simple que ça (pas besoin de composition en réalité) :

Le code fourni n'est qu'un exemple.
Les class que je cherche à coder doivent appeler des méthodes différentes.
14/10/2009, 14h03
hibour

Citation:

Envoyé par entreprise38

hibour, certes, "ça marche", mais cela revient à te faire des brochettes avec un lance-flammes plutôt qu'un barbecue 8-)

Je pense que l'utilisation d'une classe intermédiaire abstraite c'est le lance flamme pour un barbecue :mouarf: d'où ma proposition simpliste, dèja on a aucune information sur le fonctionnel des classes AAxx ;)
14/10/2009, 14h43
Patriarch24

Citation:

Envoyé par Pierre8r

Le code fourni n'est qu'un exemple.
Les class que je cherche à coder doivent appeler des méthodes différentes.

Le mieux je pense, ce serait de filer le vrai code, quitte à changer tes noms de méthodes et de classe, parce que sinon on va pas s'en sortir.

En un mot, la composition va te permettre de déléguer le comportement à une autre classe/hiérarchie de classes.