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.

[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