Title: RE: Construction d'un GUI Swing

Bon, allez, je vais avoir l'air (légèrement) lourd, mais j'essaie
de défendre ma paroisse.

> - Il n'est pas possible d'utiliser les pratiques courantes de la
> programmation objet, comme le polymorphisme

Je ne suis pas trop d'accord sur ce point. Avec certains builders,
il est possible d'utiliser tes propres contrôles dérivant des contrôles
SWING de base. A ce moment là, libre à toi de mettre en place une
architecture te permettant de paramétrer ces contrôles.

De toute façon, comme on en a déjà discuté lors d'un précédent thread,
il ne faut pas utiliser les Swing de base directement. A partir de là,
si ton builder ne te permet pas d'utiliser tes propres contrôles,
vaut mieux le jeter.

Je suis d'accord pour dire que ca n'est pas la panacée, loin de là.
Mais, il me semble que la construction d'interfaces graphiques
nécessite une approche différente du reste de la programmation objet,
légèrement plus pragmatique.

Je ne me demande pas pourquoi les constructeurs d'IHM les plus utilisés
sont des "choses" comme Visual Basic, PowerBuilder, Accèss, etc...
Outre le fait qu'il sont plus faciles d'approche, quand tu veux ajouter
un bouton, tu ajoutes un bouton, tu ne fais pas un factory pour appeler
un objet sérialisé dont le nom est dans un annuaire JNDI que tu appeles
via SOAP. 
Ah, c'est sûr, c'est moins modulaire !!!

Désolé, je m'emporte un peu. Ca doit être l'approche du week-end.

Néanmoins, le problème d'optimisation est issu de la lenteur généralisée
des JFC. Quand ce problème sera résolu (d'une manière ou d'une autre),
ON pourra peut être éviter de monter des usines à gaz pour faire des
choses simples.

> - Difficile de maintenir les differentes versions, surtout quand
> plusieurs personnes vont editer le meme panneau (par exemple, probleme
> quand tu fais un diff avec CVS)

Là, effectivement, ca peut poser un problème si l'éditeur se met à tout
réaménager.

>
> L'ideal:
>
> - Utilise le builder pour creer ton interface
> - Une fois que tu es satisfait, recupere le code et rearrange-le a ta
> facon (abstraire les methods dans une classe commune, utiliser
> l'heritage, etc...)

Malheureusement, TU en es peut-être satisfait, mais croire que ton interface
ne va jamais bouger me paraît un peu risqué (un petit champ supplémentaire
au milileu ?)

Olivier

>
> --
> Cédric
>

Répondre à