Bonjour;
 
Je dois réaliser une application client/serveur en java (client lourd) et je voulais savoir quels sont les design pattern les plus importants que je peux implémenter.
 
Merci;

get/set
 
C'est un pattern implémentant l'accès uniforme

c'est pas comme ça qu'on utilise les DP. on sort pas ça pour se la pêter devant les filles.

je sais pas si c'est un DP (surement, y en a pour tout), mais dans tous les cas, c'est toujours important d'abstraire la couche réseau => vers des classes "stubs", comme en RMI.
 
et pkoi pas utiliser RMI tout court

si, quand même un peu ...

bon ben commence par lire la bible alors...

 
Proposer du RMI ne sachant pas du tout ce qu'il veut faire : pas top.

ah bon

Salut ma belle... Tu veux voir mon builder ?
 
Tiens, justement, quand j'étais à l'école, après avoir boulcé un dossier client/serveur en C/java, la question du cours de design patterns avait été "A la lecture du cours, quels sont patterns que vous avez ou que vous auriez pu implémenter dans votre dossier ?" ...
 
La question est peut-être tout simplement celle d'un exo ou d'un TP.

ben on verra au cours du dev les questions qui se posent.
 
à part qu'un C/S c'est globalement un Command et que un interprêteur de commandes c'est un visiteur ; et j'ai tendance à les faire bien typés (le truc académique quoi), même si ça fait beaucoup de boilerplate, j'aime pas trop les desing à trou, soit on prétend qu'on a un métier qui doit tenir la complexité, soit on donne dans la bidouille, mais alors on empile pas les couches.

je vois pas quel mal y a à "proposer" ...

 
Au vu de la question, il ne sait pas ou il met les pattes. S'il essaye tout ce qu'on lui "propose a l'aveugle" il ne s'en sortira pas d'aussi tot. Ce n'est pas un mal que de proposer, mais attendre de savoir quel est le probleme avant de le faire est mieux.  
 
Exemple : s'il desire avoir du callback asynchrone dans une application CS ou le client est embarque ou est mobile, utiliser RMI risquera d'etre une vraie galere (problemes d'autorisation et d'existence d'une registry, et surtout besoin de fermer explicitement la communication, etc. ne sont que qqes exemples qui me font dire RMI non merci)
 
Mais ca reste AMHA bien entendu, tu en fais ce que tu veux.
 

j'en pense que RMI dans les mobiles tu peux oublier, et que je vois toujours pas de mal à signaler l'existence d'un outils, même avant de connaître le besoin. Dans tous les cas, ca peut servir à d'autres.
 
de toute façon, on peut discuter tant qu'on veut, tant que notre ami ne sera pas revenu en détaillant ce qu'il veut, on ne fera que spéculer

il y a ce tres bon livre/site sur les patterns pour ce genre de chose :
 
http://www.cs.wustl.edu/~schmidt/POSA/

benou :  
 
application java mobile != application java dans les mobiles

 
Mouais, ca sent la branlette intellectuelle  
 
Sinon "Le Yanis" c'est le nom d'une boite "select" (lire echangiste...) qui s'est montée en 1997 pas loin d'ou ou j'etais étudiant...
 
T'es pas le gérant par hasard ??  

c'est pas ce que dit google
 
t'entends quoi toi par java mobile ?

 
Je souhaite seulement séparer les classes IHM avec celle du métier pour éviter d'utiliser le modèle (classes métiers) directement de l'IHM et pour l'evolution et la maintenance de l'application.
Sachant que c'est application C/S, c'est pour cela j'ai pensé utiliser un design pattern du style : facade ou MVC ?
Quel votre avis ?

bha oui ... faut faire du mvc, c'est ce qu'on t'as conseillé ...
 
mais si tu me réponds pas, évite de quoter mon message

oulà ça marche dans l'autre sens.
les IHM sont *obligées* de maitriser le métier auquel elles se rapportent.
par contre le métier doit en savoir un minimum sur les interfaces qui le représentent (juste offrir les données à afficher, et des méthodes pour interragir depuis l'interface).
 
en gros modification du métier => modification de l'interface, mais pas dans l'autre sens (bien entendu, on transige un peu pour des raisons de performance, le modèle présente "comme par hasard" les données sous un format qui arrange bien la vue etc.)