IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien Help Desk
    Inscrit en
    janvier 2013
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Technicien Help Desk
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2013
    Messages : 2
    Points : 1
    Points
    1
    Par défaut Débutant - Besoin d'aide sur un petit projet à visée autodidacte
    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.

  2. #2
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 931
    Points
    2 931
    Par défaut
    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.

  3. #3
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien Help Desk
    Inscrit en
    janvier 2013
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Technicien Help Desk
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2013
    Messages : 2
    Points : 1
    Points
    1
    Par défaut
    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

  4. #4
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 931
    Points
    2 931
    Par défaut
    Citation Envoyé par glamdrick Voir le message
    • 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.

    Citation Envoyé par glamdrick Voir le message
    • 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

    Citation Envoyé par glamdrick Voir le message
    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

Discussions similaires

  1. Réponses: 3
    Dernier message: 09/04/2008, 14h24
  2. Besoin d'aide sur 3 petits programmes en Cobol
    Par gecko64 dans le forum Cobol
    Réponses: 2
    Dernier message: 12/09/2007, 22h30
  3. [VB6 + Excel] besoin d'aide sur 3 petits points
    Par Mackouacloth dans le forum VB 6 et antérieur
    Réponses: 2
    Dernier message: 12/07/2007, 16h09
  4. [Débutant] besoin d'aide sur les web services
    Par Diangelita dans le forum Services Web
    Réponses: 3
    Dernier message: 20/01/2006, 08h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo