Discussion :

[cmako]

J'ai une petite question, pourquoi on utilise plus souvent cette methode :

Code :

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

1
2
3
4
5
6
public class ToDoFrame extends JFrame {
 
 public ToDoFrame extends JFrame(){
  super("To Do Frame");
  this.setSize(300,200);
  this.setVisible(true);

plustot que celle-ci :

Code :

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

1
2
3
4
5
6
7
8
9
public class ToDoFrame
{
 private JFrame cadre;
 public ToDoFrame(){
  cadre = new JFrame("To Do Frame");
  cadre.setSize(300,200);
  cadre.setVisible(true);
 }
}

Toutes les deux donnent le même résultat mais je trouve la deuxième plus simple.

[remika]

Déjà c'est le contraire c'est plus compliqué...

Par exemple pour obtenir la taille tu fais un

Code :

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

ta_frame.getFrame().getSize()

au lieu d'un

Code :

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

ta_frame.getSize()

Ensuite c'est beaucoup plus logique, ta fenêtre EST une JFrame, elle ne contient pas une JFrame. Tu bénéficies logiquement et naturellement des propriétés de la JFrame en faisant un extends.

[cmako]

Déjà c'est le contraire c'est plus compliqué...

Par exemple pour obtenir la taille tu fais un

Code :

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

ta_frame.getFrame().getSize()

au lieu d'un

Code :

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

ta_frame.getSize()

Ensuite c'est beaucoup plus logique, ta fenêtre EST une JFrame, elle ne contient pas une JFrame. Tu bénéficies logiquement et naturellement des propriétés de la JFrame en faisant un extends.

Pour moi (débutant), il est plus simple de créer une fenêtre comme on crée un objet.
Et si je veux créer plusieures fenêtres?

[remika]

Si ta Frame est basique il n'y a aucun intérêt à l'extends, c'est sûr. Mais la plupart du temps on y ajoute des composants, d'où l'extends. Si tu veux créer plusieurs frames, ba c'est très simple :

Code :

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

1
2
3
 
ToDoFrame ta_frame1 = new ToDoFrame();
ToDoFrame ta_frame2 = new ToDoFrame();

D'ailleurs tu crées tes frames comme on crée des objets

[Clorish]

Petite question supplementaire d'un debutant en java qui viens de creer sa premiere frame :

Pourquoi le constructeur est specifié "extend JFrame" ?
Je ne l'ai pas menstionné et tout semble correct.

cmako >> La methode qui t'est proposé n'est effectivement pas logique dans le cadre d'application simple et quand on debute (je suis aussi passé par la ) mais prends tout son sens quand on "pense" son projet selon les regles de la POO.

Par exemple : Tu fait as besoin d'une fenetre qui ait une taille minimum. Il te faut donc verifier lors de l'affectation du width et du height que les valeurs ne soient pas en dessous du minimum.
Dans ton cas, tu est obligé de creer une methode "SetWidth" qui teste la valeur et qui la transmet a la methode de JFrame apres une eventuelle modification.
De plus, soit la frame est declaree publique et le developpeur est suceptible de passer directement par la propriété JFrame qui courcircuite le test; Soit tu la rend privee et tu est obligé de recreer une methode par methdoes du JFrame pour y faire appel depuis ta classe.

Dans le cas qui t'est proposé : Une classe qui derive de JFrame directement, tu peux surcharger la methode du JFrame pour la completer par ton test.
Tu viens donc de "modifier" directement le comportement de la methdoe du JFRame, comme si tu etait allé modifier directement son code source.

Ce cas ne se pose pas quand on est le seul developpeur sur le projet mais prends toute sont importance dans le cadre de projet avec plusieurs developpeur, ou de conception de librairies .....

[Edit] Petit exemple concret :
- On attache une caravanne a sa voiture.
- On ne fait pas monter la voiture sur une plateforme de la caravane en reliant les roues de la caravane a l'essieu de la voiture de telle sorte que les roues de la voiture entraine les roue de la caravane .....

[Baptiste Wicht]

Petite question supplementaire d'un debutant en java qui viens de creer sa premiere frame :

Pourquoi le constructeur est specifié "extend JFrame" ?

Tout simplement parce que c'est une erreur. Un constructeur n'étend rien du tout, c'est seulement la classe qui peut étendre quelque chose. Ce code ne doit pas compiler.

[Clorish]

Tout simplement parce que c'est une erreur. [...] Ce code ne doit pas compiler.

Je prefere ca
C'est plus logique :p

[yann2]

Bonjour

Petite question supplementaire d'un debutant en java qui viens de creer sa premiere frame :

Pourquoi le constructeur est specifié "extend JFrame" ?
Je ne l'ai pas menstionné et tout semble correct.

cmako >> La methode qui t'est proposé n'est effectivement pas logique dans le cadre d'application simple et quand on debute (je suis aussi passé par la ) mais prends tout son sens quand on "pense" son projet selon les regles de la POO.

Par exemple : Tu fait as besoin d'une fenetre qui ait une taille minimum. Il te faut donc verifier lors de l'affectation du width et du height que les valeurs ne soient pas en dessous du minimum.
Dans ton cas, tu est obligé de creer une methode "SetWidth" qui teste la valeur et qui la transmet a la methode de JFrame apres une eventuelle modification.
De plus, soit la frame est declaree publique et le developpeur est suceptible de passer directement par la propriété JFrame qui courcircuite le test; Soit tu la rend privee et tu est obligé de recreer une methode par methdoes du JFrame pour y faire appel depuis ta classe.

Dans le cas qui t'est proposé : Une classe qui derive de JFrame directement, tu peux surcharger la methode du JFrame pour la completer par ton test.
Tu viens donc de "modifier" directement le comportement de la methdoe du JFRame, comme si tu etait allé modifier directement son code source.

Ce cas ne se pose pas quand on est le seul developpeur sur le projet mais prends toute sont importance dans le cadre de projet avec plusieurs developpeur, ou de conception de librairies .....

[Edit] Petit exemple concret :
- On attache une caravanne a sa voiture.
- On ne fait pas monter la voiture sur une plateforme de la caravane en reliant les roues de la caravane a l'essieu de la voiture de telle sorte que les roues de la voiture entraine les roue de la caravane .....

L'héritage n'est pas une règle. Pour information

Personellement je préfère la composition. La délégation est facilement générable par un IDE digne de ce nom.

Pour reprendre l'exemple du setWidth, tu fais comment si tu veux interdire le changement de la largeur quand tu fais de l'héritage ?

Au pire tu fais (gros problèmes en vue) :

Code :

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

1
2
3
4
5
6
 
public class MaFrame extends JFrame {
  [...]
  public void setWidth(int width) {}
  [...]
}

et au mieux ça devient

Code :

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

1
2
3
4
5
6
7
8
 
public class MaFrame extends JFrame {
  [...]
  public void setWidth(int width) {
    throw new UnsupportedOperationException();
  }
  [...]
}

Avec la composition il suffit de ne pas écrire la méthode qui délègue l'appel.

En fait ça dépend de ce qu'on veut faire :
- Un composant générique utilisé tout au long de l'application (héritage, et encore ce n'est pas si évident).
- Une vue (composition).

L'héritage devient nécessaire lorqu'il faut redéfinir des méthodes automatiquement appelées par l'API Swing (je pense au paint(Graphics) notamment).

[edit]
D'ailleurs l'API Swing c'est beaucoup d'héritage mais c'est aussi énormément de la composition (Component 1-->* Component)
[/edit]

PS : je n'ai rien compris à l'exemple de la voiture et de la caravane. C'est peut être pour ça que je préfère la composition

yann

[Clorish]

J'ai du mal a comprendre le role de la composition.
Je viens de delphi et la bas, j'ai plutot gerer les classes par heritage.

Mais si j'ai bien compris, la composition c'est la creation d'une classe qui declare une variable privee de type JFrame (dans ce cas la) et qui redefini les methdoes de JFrame au sein desquelles on fait appel au methodes de la classe JFrame non ?
Sacre boulot en perspective .....

Quand au fait d'interdire la modification de la taille par setWidth, je ne vois pas en quoi cela est genant ....
Sous delphi ca passait plutot bien en tout cas.

D'ailleur plutot que de faire :

Code :

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

public void setWidth(int width) {}

J'opterais plutot pour :

Code :

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

public void setWidth(int width) {super.setWidth(this[ou super].getWidth())}

L'exemple de la caravane ? laisse tomber ... :p delire personnel ....
Je voulais juste faire ressortir le fait que bien souvent on etends (qui donne d'ailleur extends) les capacités d'un objet en lui rajoutant des fonctionnalités (ie la caravane connecté a la voiture) plutot que de creer un objet qui possede les nouvelles capacites et qui contient l'objet de base dont les fonctionnalités sont connectes a l'objet final (ie : La voitrue qui monte dans la caravane, dont le systeme moteur est relié a celui de la voiture).
Vous avez jamais vu ces velo, fixés sur des barges ? Quand on pedale, les roues sont tourner des rouleaux qui entraines des "aubes" pour faire avancer le "velo-pedalo"

[yann2]

J'ai du mal a comprendre le role de la composition.
Je viens de delphi et la bas, j'ai plutot gerer les classes par heritage.

Mais si j'ai bien compris, la composition c'est la creation d'une classe qui declare une variable privee de type JFrame (dans ce cas la) et qui redefini les methdoes de JFrame au sein desquelles on fait appel au methodes de la classe JFrame non ?
Sacre boulot en perspective .....

Quand au fait d'interdire la modification de la taille par setWidth, je ne vois pas en quoi cela est genant ....
Sous delphi ca passait plutot bien en tout cas.

D'ailleur plutot que de faire :

Code :

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

public void setWidth(int width) {}

J'opterais plutot pour :

Code :

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

public void setWidth(int width) {super.setWidth(this[ou super].getWidth())}

L'exemple de la caravane ? laisse tomber ... :p delire personnel ....
Je voulais juste faire ressortir le fait que bien souvent on etends (qui donne d'ailleur extends) les capacités d'un objet en lui rajoutant des fonctionnalités (ie la caravane connecté a la voiture) plutot que de creer un objet qui possede les nouvelles capacites et qui contient l'objet de base dont les fonctionnalités sont connectes a l'objet final (ie : La voitrue qui monte dans la caravane, dont le systeme moteur est relié a celui de la voiture).
Vous avez jamais vu ces velo, fixés sur des barges ? Quand on pedale, les roues sont tourner des rouleaux qui entraines des "aubes" pour faire avancer le "velo-pedalo"

Donc au final l'héritage de widget c'est bien pour redéfinir un comportement (ce qui n'est pas fait dans l'exemple de la TodoFrame, il y a juste de l'initialisation et il est facile de rendre le widget accessible).

Opter pour ça :

Code :

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

public void setWidth(int width) {super.setWidth(this[ou super].getWidth())}

est très dangereux. Le code ne fait pas ce qui ait attendu et il n'y a pas de message d'erreur. Un développeur peut s'arracher les cheveux longtemps s'il n'a pas les sources de la classe.

yann

[Clorish]

Donc au final l'héritage de widget c'est bien pour redéfinir un comportement (ce qui n'est pas fait dans l'exemple de la TodoFrame, il y a juste de l'initialisation et il est facile de rendre le widget accessible).

Oui c'est vrais que si la classe derive n'a pour role que de creer une instance de la classe mere et l'initialiser, c'est inutile.
Quand a creer uen classe qui publie la JFrame et l'initialise dans so nconstructeur .... ou bien creer un derivé initialisé dans son propre constructeur, c'est une question de vision des choses. Sous delphi ca se fait. En java, je ne sais pas La philosophie de concpetion est peut etre differente ....

Opter pour ça :
Code :
public void setWidth(int width) {super.setWidth(this[ou super].getWidth())}
est très dangereux. Le code ne fait pas ce qui ait attendu et il n'y a pas de message d'erreur. Un développeur peut s'arracher les cheveux longtemps s'il n'a pas les sources de la classe.

Tout a fait d'accord !
Mais c'est un des moyen les plus rapide est des plus simple a mettre en place.
De toute facon, une classe ne devrais jamais etre livree sans sa doc

[yann2]

Bonjour

De toute facon, une classe ne devrais jamais etre livree sans sa doc

Tout à fait d'accord . La documentation est la meilleure solution !!!

yann