Discussion :

[storm_2000]

Bonjour, j'ai une application avec plusieurs partie :
IHM (Console - Web - GUI).
Application (Les traitements).
Metier (Les classes métiers).
Persistance (Permet de stocker les différents objets métier créer).

J'aimerais savoir si il existe un ou plusieurs pattern pour séparer de façon logique toute l'application afin de limiter les dépendance aux maximum et de pouvoir faire évolution l'application rapidement ?

merci

[wazup]

Ouf !

Je peux t'indiquer un lien sur les core j2ee patterns,

bien sûr un tantinet orientés java , mais un pattern de conception,

c'est avant tout un principe.

http://www.corej2eepatterns.com/Patterns2ndEd/index.htm

[chaplin]

Il y a quelques mois j'ai voulu apprendre le C#, et j'ai télécharger le Cours C# 2008 de Serge Tahé qui parle du modèle 3 couches.
Il utilise une approche didactique qui permet de comprendre comment on passe d'un modèle monobloc à un modèle 3 couches.

J'ai particulièrement bien aimé ce cours.

[hegros]

Beh le pattern couche Ensuite il en existe pleins de variantes dont MVC qui est trés réputé

[wiztricks]

Bonjour, j'ai une application avec plusieurs partie :
IHM (Console - Web - GUI).
Application (Les traitements).
Metier (Les classes métiers).
Persistance (Permet de stocker les différents objets métier créer).

J'aimerais savoir si il existe un ou plusieurs pattern pour séparer de façon logique toute l'application afin de limiter les dépendance aux maximum et de pouvoir faire évolution l'application rapidement ?

merci

Hormi l'IHM ou il n'est pas commun de vouloir supporter et console et WEB et GUI, la description de l'application est bien trop générique pour recommander quoi que ce soit.

Personnellement, je pars plutôt avec une modélisation de type "domaine" dans laquelle j'essaie de mettre en évidence les flux d'informations, les activités, les rôles et les responsabilités.
A partir de là, on peut construire des brouillons de structures statiques (diagramme de classes) et d'activités (diagramme d'activités).

Classes et activités permettent de visibiliser les dépendances.

Pour les réduire, il va falloir "regrouper" et définir des "facades" (ou des interfaces) qui seront utilisées pour se relier aux objets externes aux "groupes". Il y a au moins 2 façades/interfaces: les fonctionnalités/services offerts et les fonctionnalités services extérieurs utilisés.

Il n'y a pas de "bonnes" méthodes pour faire de bon regroupements, seulement quelques principes (et les patterns sortent lorsqu'on essaie de les satisfaire):

• cohésion : mettre "ensemble" les éléments qui devront coopérer de toutes façons.
  
• séparation/tests: si l'application doit être construire par "morceaux", il va falloir pouvoir les tester indépendamment les uns des autres. Cela peut paraître redondant avec "cohésion", mais ici on va essayer de répondre aux questions quels tests et comment tester.
  
• construction : à priori, on va commencer par le gros oeuvre, les éléments structurants puis on va aller dans les détails. Dans les "morceaux" définis précédemment, nous allons définir par où commencer et les détails à affiner d'abord.
  
• généralisation : lorsqu'on a fait l'exercice cohésion, séparation, construction on se rencontre parfois des structures répétitives qu'il sera peut être utile de factoriser - moins de code, moins de tests et meilleure lisibilité.

Arrivé ici, le sujet a pris forme et nous pouvons le secouer un peu

• maintenabilité : il y a toujours des bugs! Avec quelles informations faire un diagnostic? Qu'implique le test d'une correction et sa livraison?
  
• évolution : que signifient les changements à effectuer pour prendre en compte des scenarii de changements divers: charge, fonctionnalités, ...
  Quels sont les changements qui pourront être "mineurs"? Quels sont les changements qui seront "majeurs"? Est ce que les besoins de mes clients sont cohérents avec ces tracas?

-W