Cast pere vers fille ?

Version imprimable

29/03/2007, 09h41
TiTiSeb

Cast pere vers fille ?

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
29/03/2007, 09h51
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.
29/03/2007, 09h55
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?
29/03/2007, 09h56
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... }.

Voilà ce que j'aimerai faire:

Code:

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:

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.

29/03/2007, 10h20
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.
29/03/2007, 10h25
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).

Citation:

Envoyé par 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.

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.

Citation:

Envoyé par Clorish

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é ;).

Citation:

Envoyé par 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).

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:

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.

29/03/2007, 10h47
maxf1

Citation:

Envoyé par <_oodTi96Tiboo_>

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, :cry:

Citation:
Envoyé par <_oodTi96Tiboo_>
Voilà ce que j'aimerai faire:
Code:

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:

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 ).

29/03/2007, 10h58
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, :P
29/03/2007, 11h03
TiTiSeb

Citation:

Envoyé par 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, :P

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.
29/03/2007, 11h05
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 ....
29/03/2007, 11h07
Clorish

Citation:

Envoyé par <_oodTi96Tiboo_>

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 :)
29/03/2007, 11h38
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
29/03/2007, 11h39
maxf1

2 pièce(s) jointe(s)

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

Bien sur pas obligé de faire un copié collé tu peux juste t'en inspiré....
29/03/2007, 11h55
Clorish
Citation:

Envoyé par g0up1l

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:

1 2 3 Measure_image img = neaw Measeure_Image(...) img."copyFrom"(ImageIO.read());
29/03/2007, 13h52
TiTiSeb

Citation:

Envoyé par 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

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.
29/03/2007, 14h12
Clorish

Citation:

Envoyé par <_oodTi96Tiboo_>

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.

Citation:

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() :(
29/03/2007, 14h20
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"
29/03/2007, 14h22
Clorish

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

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:

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 ;)

29/03/2007, 14h34
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")