Discussion :

[Clorish]

j'ai edité mon post pour te donner uen autre solution mais nos messages se sont croisé

[TiTiSeb]

Non c'est pas aussi compliqué que ca.

j'ai mal compris ce que tu voulais dire par liste mais en fait c'est plutot un tableau de Measure_Image que j'utilise.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
private Measure_Image[] Texture = null;
...
public void Add_Texture(Measure_Image Buffer){
	if (Texture == null)
		Texture = new Measure_Image[]{Buffer};
	else{
		Measure_Image[] Tmp = new Measure_Image[Texture.length+1];
		for (int i=0; i<Texture.length; i++)
			Tmp[i]=Texture[i];
		Tmp[Tmp.length-1] = Buffer;
		Texture = Tmp;
	}
}

edit : oui je vois

[Clorish]

dans ce cas si ton tableau est un tableau defini comme type principal "Measure_Image" je ne vois pas d'objections a utiliser une classe avec un membre privee de type BufferedImage au lieu d'une derivation ...

LA derivation est en fait indispensable a partir du moment ou tu souhaite stocker ton instance dans une classe qui devra la restituer plus tard pour la manipuler en tant que Measure_Image; ET, que cette classe ne supporte QUE des BufferedImages (ou parents) ET dont tu ne possede pas la possibilite d'en modifier le code source ....

Dans ce cas, ton measure_image doit obligatoirement etre un descendant de BufferedImage pour etre manipuler par la classe en question ET possder les methodes de Measure_Image pour etre manipule plus tard.

D'autre par, une autre solution consisterais a ne manipuler que des BufferedImage, en tant que tels, et les lier a une instance de MeasureImage le temps d'un calcul, voir pourquoi pas creer une classe MEasure_Image proposant des methodes statique de traitement sur des BufferdImage passes en parametres .... Comme cela tu t'affranchi de toutes contraintes hierarchiques.

Mais pour cela il ne faut pas que tes methodes fassent appel a des variables privees mais etre independantes (ce que j'appelle une classe d'"APIs")