Publicité
+ Répondre à la discussion
Page 3 sur 3 PremièrePremière 123
Affichage des résultats 41 à 43 sur 43
  1. #41
    Membre du Club
    Inscrit en
    octobre 2004
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 31

    Informations forums :
    Inscription : octobre 2004
    Messages : 124
    Points : 56
    Points
    56

    Par défaut

    Le ObjImplements3 est le seul qui sépare données et traitements, l'héritage couple étroitement données et traitements dans les deux premiers exemples.
    Dans l'exemple que tu fournis, cela n'a évidemment aucune importance, mais ramené à l'échelle d'une application, tu retrouves les bénéfices de cette séparation :
    - permettre à deux développeurs de bosser sur des couches différentes
    - ne pas être dépendant d'api techniques qui empêcheraient la réutilisation du modèle métier (ex. créer une méthode qui enregistre/supprime/recherche un client dans l'objet du domaine client lui-même est stupide, car alors la classe Client se retrouverait couplée à une API d'accès aux données => réutilisation difficile dans une autre application)
    - Faciliter la répartition des données et des traitements sur les différents tiers d’une architecture n-tiers
    - + les autres arguments des docs dont les liens ont été fournis ci-dessus...

    @+

  2. #42
    Expert Confirmé Sénior
    Avatar de Immobilis
    Inscrit en
    mars 2004
    Messages
    6 551
    Détails du profil
    Informations forums :
    Inscription : mars 2004
    Messages : 6 551
    Points : 7 247
    Points
    7 247

    Par défaut

    Citation Envoyé par djflex68 Voir le message
    - ne pas être dépendant d'api techniques qui empêcheraient la réutilisation du modèle métier (ex. créer une méthode qui enregistre/supprime/recherche un client dans l'objet du domaine client lui-même est stupide, car alors la classe Client se retrouverait couplée à une API d'accès aux données => réutilisation difficile dans une autre application)
    Me semble etre l'élément le plus important, mais stupide pas forcement. Tout dépend de la taille de l'application.

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  3. #43
    Membre du Club
    Inscrit en
    octobre 2004
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 31

    Informations forums :
    Inscription : octobre 2004
    Messages : 124
    Points : 56
    Points
    56

    Par défaut

    mais stupide pas forcement. Tout dépend de la taille de l'application
    Tout à fait, stupide n'est pas vraiment le mot qu'il fallait utiliser, disons plutôt qu'il faut éviter de le faire lorsque l'application est suceptible d'être ou de devenir relativement conséquente.

    A ce sujet, même si ce modèle est aujourd'hui largement répandu, il n'est pas non plus exempt de tout défaut (mais en design logiciel, il n'existe pas de solution miracle, tout est affaire de compromis).
    Voir par exemple les remarques émises par Martin Fowler dans sa discussion sur l'anti-pattern "Anemic domain model" (lien wikipedia http://en.wikipedia.org/wiki/Anemic_Domain_Model).
    Tu retrouveras également ici les avantages et inconvénients de cette manière de concevoir une application.

    @+

+ Répondre à la discussion
Cette discussion est résolue.
Page 3 sur 3 PremièrePremière 123

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •