Comme on pourrait faire class Truc extends ArrayList ou Vector, est-il possible de faire class Truc extends Color[] (par exemple) ?
 
Je voudrais extends un tableau en fait mais les [] gène le compilateur. La "classe" des tableaux de base a t'elle un nom ?
 
 
J'ai fait quelques recherches mais je ne trouve pas on dirait qu'on ne peut pas faire ce que je souhaite...
 
 
Pourquoi je ne veux pas utiliser de ArrayList à la place ? Ben pour des questions de performances et de casse-couillage (colors[i][j] est quand meme mieux que (Color)(((ArrayList)rows.get(i)).get(j))

Bin c'est le contenu de ton tableau que tu dois étendre, pas le tableau lui meme. Un tableau c'est un tableau hein!
 
Tu fais juste class Truc extends Color puis tu fais un tableau de Truc.

Faut faire gaffe, y'a des classes du JDK qu'on peut pas étendre. Ex: String

Ce que je souhaite c'est bien étendre le tableau et pas son contenu. Mais l'utilité de faire une telle chose est tout de meme discutable.

- Un tableau, ce n'est pas un objet à proprement parler, donc, non, tu ne peux pas "étendre" un tableau.
- les classes du JDK qu'on ne peut pas étendre sont les classes final.

Tu veux étendre le tableau, mais pkoi faire???
 
A la limite, tu crées une classe, qui utilise des arraylist, ou ce que tu veux, et tu y ajoutes une méthode  
 

, ce qui te permet de n'écrire qu'une fois le fameux (Color)(((ArrayList)rows.get(i)).get(j))

 
quelle fonctionnalité tu veux en plus?

mais tu veux faire quoi exactement? quel intéret d'étendre le tableau???

length, stro chiant à recoder

C'est pas si dur en fait

Ben en fait je fais un jeu de briques et j'aurai voulu avoir une classe Rows extends ArrayList et je rajoute dedans des instances de Column extends Color[]. Je ne sais pas si ca aurait vraiment été un plus mais j'aurais trouvé ca sympa.

Mais pourquoi, bordel ? Faire un extends pour faire un extends, ça veut rien dire et ça sert à rien
"Tiens, aujourd'hui j'vais faire un extends de LinkedHashSet, pour le fun. Demain ça sera un extends de ColorChooserComponentFactory"

 
Ca n'a rien à voir.
Le 'extends' porte bien son nom, ça permet d'étendre les possibilités de la classe mère. Mais là il n'y a rien de commun entre tes classes mères et les classes dérivées !
 
Il vaut mieux créer une classe Row qui peut contenir un tableau de colonnes Column[]. Et tu mets tes Row dans un ArrayList

J'aurai voulu rajouter des methodes du genre "est ce que le tableau est rempli (aucun element n'est nul)" ou bien "afficher en utilisant un Graphics passé en argument". Moi je trouve que ca aurait mieux séparé mes objets plutot que de mettre dans la meme classe les methodes qui travaille sur une ligne et sur la grille (plusieurs lignes).

Ba extends ArrayList, alors

Tiens en parlant de ColorChooser, c'est facile de changer son aspect, de le rendre plus light et moins encombrant ?
 
Par facile j'entend des models deja fait qu'il suffit de passer en parametres, à l'inverse d'un truc ou il faudrait tout tout redéfinir (je parle pas des méthodes mais des attributs).

 
Tu peux spécifier les panneaux dont tu n'a pas besoin ou en ajouter d'autre de ta création.
http://java.sun.com/docs/books/tut [...] eviewpanel

 
extends AbstractList  

 
Ca, ok, ça peut se justifier.
 
[citation]
 "afficher en utilisant un Graphics passé en argument".
[/citation]
 
Ca, par contre, c'est pas top : la classe qui gère les données (tes couleurs, si j'ai tout bien compris) ne devrait pas être celle qui dessine!! Pour faire n truc plus propre, et plus évolutif, il te faudrait une interface Renderer, qui a des méthodes permettant de dessiner une cellule que la classe de gestion lui passe : comme ça, si tu veux changer de manière de dessiner (genre, changer le design des briques d'un niveau à l'autre), ben tu écris une nouvelle implémentation de renderer, mais tu n'a pas à toucher à ta classe de gestion.
 
MVC powah, quoi!

Mais c'est quoi les relations entre les classes alors ?
Je saisis pas qui implemente quoi.

euuuh...alors...
 
- la classe TonRenderer implémente l'interface Renderer, qui définit la méthode dessineBrique(TonObjetQuiRepresenteUnBrique, Graphics g);
 
- la classe qui gère les données, donc, celle qui hérite de ArrayList, là, implémente (tant qu'à faire les choses, autant les faire bien) l'interface TonModele, qui définit des méthode permettant de récupérer les instances de TonObjetQuiRepresenteUnBrique a des coordonnées donnée, ou qui permet d'ajouter ou d'enlever une ou plusieurs briques, etc..
 
- Pour dessiner, ta classe d'interface graphique a un renderer, et un modèle : elle demande au renderer de dessiner la liste de briques fournies par le modèle, en lui donnant son Graphics.
 
Ca te permet de changer l'un ou l'autre des éléments sans toucher aux autres! Et donc, de facilement changer le design des briques, par exemple, ou de changer le type d'interface graphique, pour remplacer le Swing par de l'AWT ou du SWT ou n'importe quoi d'autre.
 
Regarde comment sont fait les trucs du même style dans l'API swing : JTable est un bon exemple.

ben tu fais ca alors:

et

 
pas mieux !!!

ca dépend de tes pointeurs

 
pô de pointeur en Java