Discussion :

[TiTiSeb]

bonjour,

j'ai un probleme conceptuel. J'aurai besoin dans mon programme de "caster" un object d'une class pere en dans une class fille. Or bien sur cela est interdit. mais je sais pas comment contourner le problème.

J'ai créé une class fille de BufferedImage soit Measure_Image. Dans la classe fille, Measure_Image, j'aimerai faire un construteur qui prend un chemin de fichier est contruit un Measure_Image par la methode "ImageIO.read()". Or cette method return un BufferedImage et non un Measure_Image.

comment puis je contruire un Measure_Image à partir d'un fichier?

ImageIO.read() me parait tout indiquée mais comment contruire un Measure_Image avec cette methode car elle retourne un BufferedImage?

merci de votre aide.
TiTi

[maxf1]

Cela est faisable mais il va falloir faire un constructeur spécial dans ta classe fille avec en parametere un pere.
Du moins c'est comme cela que je le ferais à premiere vu.

[TiTiSeb]

mouais j'aime aps trop devoir contruire un object pere pour le filer à un fil. j'aimerai tout encapsuler dans le fil.

enfin je sais pas si c'est faisable.
si je te suis, comment dans le contructeur du fil qui prend un pere tu construis le fil?

[gifffftane]

Je crois que tu mélanges un peu les notions. Caster un objet père en fille n'est pas du tout interdit - du moins en java.

Mais caster en java, pour les objets, n'est pas une opération qui transforme un objet en un autre, mais seulement transforme son apparence déclarée dans l'écriture.

Si tu veux, à partir d'un BufferedImage, obtenir un nouvel objet, de quelque type qu'il soit, il faut que le nouvel objet intègre une méthode ou un constructeur qui lui permette de tenir compte des informations données. Et le fait que l'un hérite de l'autre n'a pas d'importance à ce niveau là.

Donc il faut que tu écrives un truc style (par exemple ici un constructeur) : Measure_Image(BufferedImage imageOrigine) {... ici, à toi de faire... }.

[TiTiSeb]

Voilà ce que j'aimerai faire:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public class Measure_Image extends BufferedImage{
...
public Measure_Image(String Pathname) throws IOException{
	super();
	File file = new File(Pathname);
 
	if (!file.isFile())
		throw new IOException("Cannot find: " + Pathname);
 
	Buffer = ImageIO.read(new BufferedInputStream(
			new FileInputStream(file)));
}

ce que j'avais fait c'etait ca mais j'aime pas trop. en plus ca fonctionne pas car il ne veux aps caster les BufferImage en Measure_Image.

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
16
17
public class Measure_Image extends BufferedImage{
...
public Measure_Image(...)
...

public Measure_Image LoadImg(String Pathname) throws IOException 
{
	File file = new File(Pathname);

	if (!file.isFile())
		throw new IOException("Cannot find: " + Pathname);

	Measure_Image buffer = (Measure_Image)ImageIO.read(new BufferedInputStream(
			new FileInputStream(file)));

	return buffer;
}

pour l'histoire du cast oui j'ai du mal m'exprimer. c'est pas transformer en mais interpreter comme.

[Clorish]

Moi ce qui me chagrine c'est que le BufferedImage est renvoyé par ImageIO.read() qui a priori est sense faire un new BufferedImage a moins que je ne me trompe.

Je ne connait pas java mais osu delphi d'ou je viens caster un objet de la classe pere a la classe fille si l'isntance est cree a partir de la classe pere est strictement interdit !
tout appel aux methodes de la classe fille retournerons une erreur car l'isntance ne possede pas ces methodes (vu qu'il a ete cree depuis la classe pere)

Cela est possible si on cree une instance de la classe fille, transmise en parametre ou sauvegardé dans une variable de type classe pere et plus tard, la re-manipuler en tant que classe fille.....

Ton probleme a mon avis ne peut se resoudre que si tu maitrise la creation de l'isntance retourné par ImageIO.read(). Il faudrais que tu soit a l'origine de la creation de cette instance.

[Clorish]

a y penser, sous delphi je ferais ceci :
- Creation d'une classe derivee de ImageIO
- reecriture de la methode (suppose protected a moins) de la methode qui cree l'isntance du BufferedImage pour creer et retourner a ImageIO une instance de Measure_Image
- ajout d'une methode read() qui retroune la valeur du bufferedimage casté (tant qu'a faire).

[TiTiSeb]

Moi ce qui me chagrine c'est que le BufferedImage est renvoyé par ImageIO.read() qui a priori est sense faire un new BufferedImage a moins que je ne me trompe.

Ca pose pas de problème en Java. enfin je crois. je le fait souvent et j'ai jamais eu de problème. Je suis comme beaucoup autodidact donc peut être que c'est interdit ??? enfin ca marche.

Je ne connait pas java mais osu delphi d'ou je viens caster un objet de la classe pere a la classe fille si l'isntance est cree a partir de la classe pere est strictement interdit !
tout appel aux methodes de la classe fille retournerons une erreur car l'isntance ne possede pas ces methodes (vu qu'il a ete cree depuis la classe pere)

Tu as tout compris à mon problème. ce que je veux faire n'ai pas autorisé .

a y penser, sous delphi je ferais ceci :
- Creation d'une classe derivee de ImageIO
- reecriture de la methode (suppose protected a moins) de la methode qui cree l'isntance du BufferedImage pour creer et retourner a ImageIO une instance de Measure_Image
- ajout d'une methode read() qui retroune la valeur du bufferedimage casté (tant qu'a faire).

ah tout ce que je voulais pas entendre . j'aimerai dans le mesure du possible pas refaire cette class.

je vous expose ce que j'ai fait pour le moment.

j'ai créer une class sans heritage. cette class contien un object BufferImage. voici le code:

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
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
public class Measure_Image {
 
	...
	public int Id;
 
	private BufferedImage Buffer;
 
	/**
         * Build an Measure_Image since file
         * 
         * @param Pathname
         * @throws IOException
         */
	public Measure_Image(String Pathname) throws IOException{
		super();
		File file = new File(Pathname);
 
		if (!file.isFile())
			throw new IOException("Cannot find: " + Pathname);
 
		Buffer = ImageIO.read(new BufferedInputStream(
				new FileInputStream(file)));
	}
 
	/**
         * return width of image
         * @return
         */
	public int getWidth(){
		return Buffer.getWidth();
	}
 
	/**
         * return height of image
         * @return
         */
	public int getHeight(){
		return Buffer.getHeight();
	}
 
 
	/**
     * Convert image to bytebuffer
     * @param bufferedImage
     * @return
     * @throws IOException
     */
    public ByteBuffer convImg2Bytes() throws IOException 
    { 
  ...
    } 
}

Ca marche cette solution mais je sais pas si c'est terrible. car en fait comme je l'ai fait pour getHeight et getwidth, il va falloir que je reinstencie tout les methode dont je vais avoir besoin de bufferImage.

si quelqu'un a mieux je suis preneur.

[maxf1]

mouais j'aime aps trop devoir contruire un object pere pour le filer à un fil. j'aimerai tout encapsuler dans le fil.

enfin je sais pas si c'est faisable.
si je te suis, comment dans le contructeur du fil qui prend un pere tu construis le fil?

Si tu ne veux pas construire un pere pour le donner a son fils, alors tu ne dois pas utilisé ImageIO.read().

Tu vas surement devoir extendre la classe ImageIO et réécrire la méthode read pour qu'elle te retourne un Mesure_Image à la place d'un BufferedImage


Edit: Ah ben si tu crée ta classe MesuredImage sans héritage de BufferedImage mais juste en contenant un objet de ce type alors c'est très bien. Ca marchera aussi sauf que tu doit "réimplementer" toute les methodes de bufferredImage dont tu auras besoin,

[g0up1l]

Voilà ce que j'aimerai faire:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public class Measure_Image extends BufferedImage{
...
public Measure_Image(String Pathname) throws IOException{
	super();
	File file = new File(Pathname);
 
	if (!file.isFile())
		throw new IOException("Cannot find: " + Pathname);
 
	Buffer = ImageIO.read(new BufferedInputStream(
			new FileInputStream(file)));
}

ce que j'avais fait c'etait ca mais j'aime pas trop. en plus ca fonctionne pas car il ne veux aps caster les BufferImage en Measure_Image.

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
16
17
public class Measure_Image extends BufferedImage{
...
public Measure_Image(...)
...

public Measure_Image LoadImg(String Pathname) throws IOException 
{
	File file = new File(Pathname);

	if (!file.isFile())
		throw new IOException("Cannot find: " + Pathname);

	Measure_Image buffer = (Measure_Image)ImageIO.read(new BufferedInputStream(
			new FileInputStream(file)));

	return buffer;
}

pour l'histoire du cast oui j'ai du mal m'exprimer. c'est pas transformer en mais interpreter comme.

et oui, en java comme en C++ les objets ne sont pas 'mutables' !
Si ton objet est créé en tant que BufferedImage, il n'a aucune chance de devenir un jour un Measure_Image ( d'où l'échec du cast ).

[maxf1]

Personellement je pense que j'aurais plutot rééecrite la méthode read de ImageIO en lui faisant retourner un Mesure_Image.

Ce n'est pas trop dur à faire, tu prend les sources de java, et lors de la constrution du bufferedImage tu met ton type et dans le type renvoyé pareil. Et hop............ le tour devrait etre joué. 3minutes montre en main,

[TiTiSeb]

Personellement je pense que j'aurais plutot rééecrite la méthode read de ImageIO en lui faisant retourner un Mesure_Image.

Ce n'est pas trop dur à faire, tu prend les sources de java, et lors de la constrution du bufferedImage tu met ton type et dans le type renvoyé pareil. Et hop............ le tour devrait etre joué. 3minutes montre en main,

Je suis d'accord avec toi, c'est plus correcte ce reecrire ImageIO.read().

Mais je t'avoue que je ne vois pas comment faire. Le source Java je ne l'aurai pas car c'est une class native de java.

[Clorish]

En fait ce que tu veux c'est faire une classe qui "manipule" les donnees d'un BufferedImage ....

Donc dans ce cas la meilleur solution est de creer une class sans extends, qui possede une variable de type BufferedImage en private, tu developpe tes mthodes des traitement et pour eviter de tout reecrire, tu n'a qu'a developper un getter et un setter pour ton "BufferedImage Buffer"

D'ailleur ca te permettra de changer une image depuis un bufferdImage directement au lieu de le chopper a partir d'un ImageIO
Plus de libertée ....

[Clorish]

Je suis d'accord avec toi, c'est plus correcte ce reecrire ImageIO.read().

Mais je t'avoue que je ne vois pas comment faire. Le source Java je ne l'aurai pas car c'est une class native de java.

regarde du cote des methodes protected proposees si ya pas un "createBufferdImage" .. souvent les developpeur mettent protected ce genre de fonctions protected pour permettre justement ce genre de choses.
Enfin moi c'est ce que je ferais

[g0up1l]

Ben, conceptuelement parlant, choisir entre un héritage ( maxf1 ) et une variable membre ( Clorish ), ce n'est pas du tout la même chose !
Je ne pense pas qu'il faille raisonner en temps de développement mais plutôt en sémantique du modèle.

Il faut que tu tu poses des quesiotns du genre :

mon objet va-t-il être 'vu' comme une Buffered Image ? Avec par exemple l'insertion dans des listes de BufferedImage ?
-> ce qui proscrit l'emploi d'une variable membre car cela limiterait l'utilisation de polymorphisme

[maxf1]

Alors voila je les ai réécrite pour toi :

Bien sur pas obligé de faire un copié collé tu peux juste t'en inspiré....

[Clorish]

Il faut que tu tu poses des quesiotns du genre :

mon objet va-t-il être 'vu' comme une Buffered Image ? Avec par exemple l'insertion dans des listes de BufferedImage ?
-> ce qui proscrit l'emploi d'une variable membre car cela limiterait l'utilisation de polymorphisme

tout a fait d'accord meme si je ne sais apas encore ce qu'est le polymorphisme
En tout cas uen chose est sur, c'est que l'usage de variable membre est de toute maniere limitatif, au moins en ce qui concerne les traitements deja ecrits sur les BufferedImage.

d'aure part, sous delphi il existait un moyen de "copier" (et non pas de "muter") une instance de classe pere dans une instance d'une classe fille.

Dans ce cas, seul les variables privees relative a la classe pere etait copié.

Il existait de cette maniere une classe Graphics, derivee sous forme de Bitmap, Jpeg, Png, etc ...
la copie d'un BMP dans un JPG avait pour but de copier que les variables communes, soit Graphics. apres libre a chacun de les utiliser ou non, avec certaines restrictions.
Une copie JPG->BMP s'executais sans bug si au prealable on avait "decompresse" l'image en memoire pour que la variable issue de Graphics contenant les octets de l'image, copie dans BMP soit exploitable par les methodes de BMP ....

On aurais qque chose du genre :

Code :

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

1
2
3
 
Measure_image img = neaw Measeure_Image(...)
img."copyFrom"(ImageIO.read());

[TiTiSeb]

Ben, conceptuelement parlant, choisir entre un héritage ( maxf1 ) et une variable membre ( Clorish ), ce n'est pas du tout la même chose !
Je ne pense pas qu'il faille raisonner en temps de développement mais plutôt en sémantique du modèle.

Il faut que tu tu poses des quesiotns du genre :

mon objet va-t-il être 'vu' comme une Buffered Image ? Avec par exemple l'insertion dans des listes de BufferedImage ?
-> ce qui proscrit l'emploi d'une variable membre car cela limiterait l'utilisation de polymorphisme

Effectivement ce que j'ai besoin c'est d'etendre la class BufferedImage car tu tombes dans le mille je l'utilise par la suite dans une liste. conceptuellement c'est ce qui s'impose car il veux rajouter des fonctionnalité à cette class.

Clorish: c'est une idée interessante mais je sais pas trop commetn copier toutes les informations du pere. mais je vais y reflechir.
maxf1: merci pour le code je vais voir si ca peux repondre à mon problème.

[Clorish]

Clorish: c'est une idée interessante mais je sais pas trop commetn copier toutes les informations du pere. mais je vais y reflechir.
maxf1: merci pour le code je vais voir si ca peux repondre à mon problème.

Je ne connait pas java mais je ne te proposais pas de le faire "a la main" car copier les donnees consiste aussi a copier les donnees privees ... sinon tu risque d'avoir des problemes.
Je parlais plutot d'un mechanisme interne propose par Java .... si cela existe.

Effectivement ce que j'ai besoin c'est d'etendre la class BufferedImage car tu tombes dans le mille je l'utilise par la suite dans une liste. conceptuellement c'est ce qui s'impose car il veux rajouter des fonctionnalité à cette class.

Oui mais ta liste : c'ets une liste de bufferdImage ? C'est a dire une classe specifique deja implementee qui a ete creee pour manipuler des BufferedImages ?
Parce que sinon tu peux herarchiser tes classes comme ca :

MonBuffuredImage
|_Measure_Image
|_AutreClass_Image

avec :
- MonBufferedImage qui possede une variable privee de type BufferedImage, accessible par set protected et get public.
- Measure_Image qui implemente les methodes specifique, qui manipule le BufferedImage de MonBufferedImage
- Idem pour AutreClass_Image avec ses propres methodes.

Ta liste elle est soit une classe perso qui gere des MonBufferedImage (instancies depuis Measure_Image ou AutreClass_Image voir meme MonBufferedImage) soit une classe existante qui manipule des types generiques tels que Object, ou autres. Dans ce cas, il faut s'assurer que MonBufferedImage derive bien de cette classe.

Si malgres tout tu est "obligé" de derriver de BufferedImage, tu n'as pas d'autre choix que ceux qui t'on ete proposé, dont la reecriture de ImageIO.Read()

[TiTiSeb]

Exactement c'est pour cela que je mettais la phrase :
"mais je sais pas trop comment copier toutes les informations du pere. mais je vais y reflechir"