Bonjour,

Je suis un peu perdu dans les classes pour mon développement d'application.
Ce qui me pose problème c'est la gestion simultannée des classes du GUI et des classes des actions que je veux faire.
Quand le GUI se résumé à System.out.println() je ne me posais pas autant de question ...

Je suis en train de faire un client Jabber.
Le point de départ de mon développement c'est donc la connexion et la configuration.
J'utilise un framework pour gérer la connexion Jabber.
Si l'on se base uniquement sur la configuration du serveur.
J'ai besoin d'un objet ConnectionConfiguration, pour créer cet objet et le modifier, j'ai besoin d'avoir les données.

Je me suis dit qu'il fallait hérité de la classe ConnectionConfiguration et de lire les propriétés si possible et d'afficher une fenêtre demandant les informations dans l'autre cas et cela dans l'objet hérité de ConnectionConfiguration.

Pour faire cela, me faut-il vraiment ces 3 objets :
- Un objet hérité de ConnectionConfiguration
- Un objet pour la lecture des propriétés
- Un objet pour la boite de Dialogue

Le deuxième problème c'est que la configuration une fois créée peut demander à être modifiée.
Or, il faut que je recréé l'objet car les champs de bases comme le server et le port ne sont pas modifiable.

Cela implique-t-il un objet intermédiaire entre l'objet hérité de ConnectionConfiguration et ma création de la configuration ? Comment faire pour demander à une classe de se régénérer ?

Ou alors l'autre solution est de demander la création de l'objet ConnectionConfiguration avant de le créer et non pendant sa création.

Pouvez-vous m'aider à éclairsir tout cela ?

Merci

Avant tout il ne sert à rien d'hériter à tout va. C'est un mécanisme de C++ (ou autre langage à héritage multiple qu'il faut essayer d'oublier). Dans ton cas la composition suffit i.e. avoir l'objet métier (la config) comme un champ dans ta classe controller/view (la fenêtre de dialogue).

Généralement les objets de configuration se présente sous la forme de service (classe statique) accessible avec des indexeur ayant pour paramètre la clé de configuration (typiquement une chaîne de caractère comme "server-port" par exemple). Cette classe devrait être indépendante du système de stockage sous-jacent qui pourrait être modéliser par des providers (tu aurais par exemple un provider GConf, un autre avec des fichiers INI, un autre avec la base de registre...). Néanmoins ce genre de truc doit déjà exister dans la bibliothèque standard de Java.

Ensuite, ce qu'il faut que tu fasses, c'est bien séparer la logique applicative (connections, configuration, gestion des utilisateurs, etc...) de la logique présentation (fenêtre, boite de dialogue, etc...). Généralement ça mène à une sorte de MVC où le GUI fait office de Vue et de Contrôleur.

Pour les paramètres "sensibles" comme le port et tout il suffit de prévenir l'utilisateur que ça requiert une déconnexion et ensuite tu recréé un objet connection comme il faut.

D'accord.
Déjà l'idée de MVC me parait très bonne.

Donc, toi tu pense qu'il faut que je fasse un objet Boite de Dialogue.
Qui contient un objet config. que je peux envoyer à la classe de connexion par une méthode getConfig() par exemple ?

Et on charge la configuration par défaut dans cette classe ddepuis le fichier de propriétés.

En utilisant le principe des classes statique tu fais en sorte que la configuration de base choisie (ainsi que le/les providers) soit initialisé automatiquement au démarrage de l'application. Pour les "providers" il y'aurait par exemple un provider qui charge la config depuis un fichier INI et un autre depuis les arguments de la ligne de commande. A toi de faire en sorte de savoir quel provider à la priorité sur l'autre (peut être en implémentant une interface Comparable et en les mettant dans une liste ordonné, ensuite il ne reste plus qu'a boucler sur cette liste jusqu'à trouver un provider qui renvoi l'information désirée).

Du coup aucun besoin d'avoir une instance quelque part puisque la configuration est accessible à tout le monde.

En tout cas, même si tu fais en sorte que ta Vue soit en réalité à la fois la Vue et le Contrôleur il ne faut jamais que tu passe un de ces objet à la couche métier/modèle.