Discussion :

[djflex68]

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...

@+

[Immobilis]

- 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+

[djflex68]

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.

@+