Discussion :

[glamdrick]

Bonjour à tous,

Par curiosité intellectuelle j'ai décidé de m'intéresser à la programmation et j'ai choisi pour cela le langage C# ainsi qu'un projet fil conducteur me servant à garder ma motivation face à l'immensité des connaissances à appréhender.

Parmi les foules de choses que je découvre, la notion d'architecture en couches me semble intéressante et j'aimerais essayer de l'appliquer à mon projet, mais je me heurte à quelques difficultés sur la répartition de mes objets. Très rapidement, je me permets d'expliquer mon projet, puis le problème pour lequel j'aurais besoin de conseils.

Mon projet consiste à simuler un jeu de plateau assez complexe. Dans ce jeu, j'ai identifié une classe Investigateur.
Si j'ai bien compris le principe N-Tier, ma classe Investigateur peut être référencée par ma couche UI, Métier et Dao, ce qui me ferait la placer dans une couche transverse. Disons Entités.

Mon problème est le suivant :

• 1. un investigateur possèdes 6 caractéristiques -> j'ai créé une classe Caractéristique
• 2. la manière de gérer ces caractéristiques peut changer selon l'Investigateur -> j'utilise le design pattern Strategy pour isoler le comportement, donc une interface et quelques classes

Question :

Dans quelles couches devrais-je placer mes classes Investigateur, Caractéristique, ainsi que mon interface et les classes associées de gestion de caractéristiques ?

Je sais bien que ça doit sembler très basique comme question, mais je commence à saturer avec toutes ces notions et j'ai du mal à faire la synthèse

Merci !

P.S. vous me pardonnerez peut-être cette sollicitation qui sort un peu du cadre de cette section du forum : j'ai également du mal du mal avec le découpage de mes classes, donc avec la conceptualisation. Si quelqu'un à un peu de temps pour que je lui explique un peu plus le projet et pour me conseiller, il peut me mp. C'est du C# mais je suppose que n'importe qui d'expérimenté en orienté objet peut m'aider là-dessus.

[Luckyluke34]

Hello,

Mettre tes entités dans une couche transverse utilisée par les autres couches est un choix d'architecture, ce n'est pas obligatoire en n-tier. Au passage, ne pas confondre n-tier (tiers = clients/serveurs souvent séparés par du réseau, par exemple : client UI, serveur d'applications, serveur base de données) et n-layer ou layered architecture (une couche applicative ne correspond pas forcément à un tier, il peut y en avoir plusieurs par tier).

Le fait que les notions d'Investigateur et de Caractéristiques soient présentes à tous les niveaux du système - UI pour l'affichage, Business pour gérer les règles métier, Data quand on veut persister les données - ne veut pas dire que ce sont les mêmes classes partout. Bien souvent, on a une couche UI qui va se contenter d'afficher des données relatives aux Investigateurs et aux Caractéristiques. Les classes de cette couche n'ont pas besoin d'être bien malines, elles contiennent juste des informations. Cf la notion de DTO. A l'inverse, la couche business est intelligente, elle met en oeuvre des règles métier, effectue des validations, etc. donc on va déclarer des classes différentes qui auront du comportement, des méthodes et pas juste des propriétés. D'après l'exemple, j'imagine que c'est plutôt dans cette couche métier que tu mettrais ton pattern Strategy puisqu'il semble porter sur la manière dont on "gère les caractéristiques".

Pour schématiser, la notion d'Investigateur pourra se décliner en :

Code :

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

1
2
3
4
5
InvestigateurAffichage

Investigateur (métier)

InvestigateurPersistence

Ecrire une couche transversale contenant toutes les "entités" et réutilisée par les autres couches peut paraître plus simple au premier abord, mais ce n'est pas forcément le meilleur choix dans un système un peu complexe. A cela s'ajoute le fait que le tier(!) qui héberge la couche UI n'utilise pas forcément la même techno ou les mêmes langages que la couche métier, donc on n'a parfois même pas le choix de réutiliser les mêmes classes dans les deux couches.

Pour comprendre un peu mieux ces notions d'architecture communément admises en développement, je te conseille le bouquin PoEAA de Martin Fowler ou son blog qui sont très bien faits.

[glamdrick]

Bonjour Luckyluke34

Merci de ta réponse. En effet tu éclaires mon problème sous un angle nouveau pour moi. Je vais réfléchir à tout ça, et aussi lire les références que tu as données.

Juste pour vérifier si je vais dans le bon sens, pourrais-je donc juste à titre d'exemple créer une classe :

• InvestigateurAffichageGUI
  
  • dans la couche UI
  • remplaçable par une autre classe ultérieurement comme InvestigateurAffichageConsole par exemple
  • qui irait chercher les infos dont elle a besoin dans la couche métier via une interface par exemple IInvestigateurAffichage, en identifiant l'investigateur via un simple nom par exemple.

• Investigateur
  
  • dans la couche métier
  • qui se compose entre autre de Caractéristique (également classe de la couche métier)
  • dont la gestion des caractéristiques est gérée via une interface et des classes également dans la couche métier

Je passe sur le reste, c'est juste pour voir si j'ai bien compris l'idée générale.

Bon, maintenant je n'ai plus qu'à m'attaquer à la lecture du blog. Ouille

[Luckyluke34]

• InvestigateurAffichageGUI
  
  • dans la couche UI
  • remplaçable par une autre classe ultérieurement comme InvestigateurAffichageConsole par exemple
  • qui irait chercher les infos dont elle a besoin dans la couche métier via une interface par exemple IInvestigateurAffichage, en identifiant l'investigateur via un simple nom par exemple.

Je pensais plus à un InvestigateurDTO côté UI qui va être une classe toute bête qui contient juste des champs de données relatives à l'investigateur à afficher. Le DTO ne va pas "chercher des infos" puisqu'il n'a aucun comportement. C'est aux classes qui représentent la plomberie de ton système d'aller chercher les infos : le Controller dans le cas d'une application web MVC par exemple, le main() de ton application console ou une de ses sous-méthodes, etc. vont peupler ton DTO avec les données récupérées.

• Investigateur
  
  • dans la couche métier
  • qui se compose entre autre de Caractéristique (également classe de la couche métier)
  • dont la gestion des caractéristiques est gérée via une interface et des classes également dans la couche métier

Oui

Bon, maintenant je n'ai plus qu'à m'attaquer à la lecture du blog. Ouille

Le bouquin est pas mal, on peut lire l'introduction pour un aperçu et ensuite aller directement aux chapitres des patterns qui nous intéressent