Discussion :

[v4np13]

Bonjour,

Je sèche sur une partie de mon travail. Je dois réaliser 3applications qui communiquent entre elles en réseau. La connection,... se passe bien mais ce sont les échanges qui posent problème.

Je m'explique: Le client doit se connecter à une banque et pour s'identifier il doit envoyer son login et mot de passe à la banque. Ce que je récupère dans l'interface graphique et je le stocke dans:

Code :

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

1
2
3
4
class SimplifiedClient{
  String name, password;
  ...
}

Pour l'envoi/réception, j'ai pensé bon de créer une nouvelle classe ObjNetwork:

Code :

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

1
2
3
4
5
6
class ObjNetwork{
  String message;
  Object obj1;
  Object obj2;
  ...
}

Elle s'adapterait en fonction du type d'envoi (NewClient, BuyStock, Disconnect,...) avec chaque fois les objets nécessaires.

Donc dans le cas de la connection, je créée un ObjToSend:

Code :

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

1
2
clientToto = new SimplifiedClient("Titi","12345");
ObjToSend = new ObjNetwork("NewClient", (Object) clientToto);

J'envoie et puis dans la banque je reçois, l'objet ObjNetwork que je traite comme suit:

Code :

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

1
2
clientToto = (SimplifiedClient)objToReceive.getObj1();
System.out.println(clientToto.getName()+" est connecté");

Les méthodes existent bien,... mais il n'arrive pas à m'afficher le nom de clientToto. J'ai l'impression que les casts dans les deux sens font que ça foire. (SimplifiedClient -> Object -> SimplifiedClient).

Dans la banque, je n'utilise pas de constructeur (étant donné que je caste). Faudrait-il en créé un, si oui comment?

Autrement comment pourrais-je faire pour transiter plusieurs variables d'un coup sans pour autant créer des nouvelles classes pour chaque type de communication?

Merci par avance pour votre aide.

[mavina]

Salut,

Pourquoi ne pas t'inspirer de certains protocoles comme FTP ?
Tu crées une "norme" dans laquelle tu pourras envoyer tes informations :

Login, password, disconnect, etc..., tout peut être géré via du texte plutot que via des objets non (ce qui simplifie les envois)?

Fred

[v4np13]

Dans mes objets, il n'y aura pas que des strings mais aussi des InetAdress, int, arraylist,...

Le plus gros du code avec ces objets est déjà écrit. Le fait de devoir réécrire en utilisant que des strings compliquerait le tout. J'ai pris la commande la plus simple pour expliquer mon problème mais que je vais devoir envoyer un arraylist, ce ne sera pas possible.

Avant de penser à tout réécrire avec des strings, j'aimerai savoir s'il n'y a pas moyen de le faire avec des objets. Ce serait plus simple pour moi.

[Napalm51]

C'est peut-être un peu bête mais tu passes bien par des ObjectOutputStream ?

[OButterlin]

Tu utilises les Socket ?

[v4np13]

Ouaip, j'utilise bien les Sockets, ServerSockets, ObjectOutputStream,...

Les classes sont bien sérialisées,... Juste la dernière étape qui coince donc le cast de l'objet vers SimplifiedClient.

[OButterlin]

ton client a bien accès à la définition de l'objet en question ?

[v4np13]

Oui, la classe SimplifiedClient est identique des différents côtés (dans la banque et dans le client). Seule différence, c'est que dans le client, j'ai le constructeur du SimplifiedClient.

[OButterlin]

oui mais alors tu as une "class cast exception"

[v4np13]

Mmmh, il ne me dit pas ça comme cela. Mais ça doit être ça, comment puis-je lui expliquer comment caster un objet en SimplifiedClient ?

[OButterlin]

Passe par une interface commune

[Pollux]

Pour que la déserialisation puisse se faire, il faut un constructeur sans argument dans ta classe. Si tu n'as mis aucun constructeur c'est bon il sera créé pour toi par le compilateur.

[v4np13]

L'objet SimplifiedClient dans l'application client est:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class SimplifiedClient  implements java.io.Serializable{
    static final long serialVersionUID = 1L;
 
    String clientName, clientPassword;
    InetAddress clientIP;
    int clientSold;
    int bankID;
 
    public SimplifiedClient(){}
 
    public SimplifiedClient(InetAddress cIP, String cName, String cPswd, int cCredit, int bID) {
        this.clientIP = cIP; 
        this.clientName = cName;
        this.clientPassword = cPswd;
        this.clientSold = cCredit;
        this.bankID = bID;
    }
 
   //méthodes
}

Dans la banque, j'ai exactement la même chose sauf que je n'ai pas le 2eme constructeur.

L'ordre de déclaration des variables a-t-il de l'importance?

Autrement, l'interface commune, je ne comprends pas comment l'implémenter, je n'ai pas encore eu l'occasion de me servir des interfaces.

[OButterlin]

Au risque de me répéter, ce ne sont pas les mêmes objets, donc problème...

Fait un test, fournis un jar de l'objet à ton client et regarde s'il arrive à le récupérer.
Tu peux fournir le plus complet à la "banque", tu n'as pas besoin d'utiliser ce constructeur.
La solution "propre" serait de faire implémenter une interface commune à tes 2 objets et là, si tu cast vers l'interface, plus de problème...

a+

[v4np13]

En quoi l'objet SimplifiedClient du client est-il différent de celui de la banque? Ils ont les mêmes variables, mêmes méthodes, juste un constructeur de plus dans le cas du client.

Pourrais-tu me donner un exemple pour l'interface commune?

Merci

[OButterlin]

L'objet a forcément une signature différente puisque tu n'as pas les mêmes méthodes (constructeur en l'occurrence)

Pour ce qui est de l'interface :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
public interface MonInterfaceCommune
{
   public void maMethode1(String parm1, Object parm2);
   ...
}
 
public class MonObjetAPartagerCoteBanque implements MonInterfaceCommune
{
   public void maMethode1(String parm1, Object parm2)
   {
      ... le traitement ...
   }
}
 
public class MonObjetAPartagerCoteClient implements MonInterfaceCommune
{
   public void maMethode1(String parm1, Object parm2)
   {
      ... le traitement ...
   }
}
 
// Après pour la récupération...
 
MonInterfaceCommune monObjetPartage = (MonInterfaceCommune)objToReceive.getObj1();

A+

[v4np13]

J'aurai toujours mes différents constructeurs, non?

Puisque l'interface peut contenir uniquement des définitions de méthodes et des valeurs constantes et non des valeurs non-constantes, ni des constructeurs.

[OButterlin]

Si tu veux...
C'est un peu comme si tu voyais l'objet sous une forme "comportementale" plutôt que sous la forme d'une instance bien précise d'un objet...

(c'est pas très beau comme terme, mais c'est relativement explicite)

A+

[mavina]

Ce qu'on te propose en fait, c'est d'utiliser une méthode qui s'appelle le polymorphisme.
Quel que soit l'objet qui découle de ton interface, il devra suivre le contrat de cette interface : memes méthodes (et pas forcément mêmes constructeurs) entre autres.

Donc tes deux clients peuvent déscendre de la même interface, ce qui te permet de pouvoir avoir un constructeur dans l'un et pas dans l'autre.

Apres, au lieu de caster en client, tu cast en interface, et tu appelle les méthodes. Java se débrouillera tout seul pour aller chercher la bonne methode selon la classe qu'il aura, mais toi tu t'en fiche, tu appelles les méthodes sur une interface.

Pour te donner un exemple, supposons une interface Voiture qui a une methode accelerer().
Deux classes Clio et Twingo descendent de Voiture, donc doivent redéfinir cette méthode accelerer() pour coller au contrat de l'interface.
Maintenant, si je récupere une voiture, et que je ne sais pas si c'est une Twingo ou une Clio, je la récupère sous la forme d'une Voiture :

Code :

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

Voiture maVoitureInconnue=getVoiture();

Or, peu importe la voiture que j'aurai récupéré, je peux accélerer avec, donc appeller la méthode accelerer(), et ce même si elles ne sont pas construites de la même façon. C'est le même principe avec tes clients

Fred

[v4np13]

Merci à vous pour vos explications, je vais essayer ça, je vous tiens au jus.