Post by s***@gmail.comBonjour,
J'aurai aimé savoir s'il était préférable qu'un objet soit quelque
chose, c'est à dire assimilable à un être concret, plutôt qu'il
s'occupe de quelque chose.
Il est impossible de répondre à cette question dans l'absolu. Du point
de vue informatique, un objet est essentiellement une instance de
l'association d'une structure de données et d'un ensemble de traitements
agissant sur cette structure de données (bref, un ADT). Qu'il soit
utilisé pour modéliser un élément du domaine ou un élément de la
solution est de ce point de vue tout à fait accessoire - à vrai dire, on
a généralement les deux cas. Dans un langage "pur objet", de toutes
façons, *tout* est un objet. En Python par exemple, non seulement tous
les types "primitifs" (numériques, chaines etc) ou complexes (listes,
tuples, dictionnaires etc) sont des objets, mais même les fonctions, les
modules ou les classes sont eux-mêmes des objets. Tu comprends que dans
ce cadre, ta question n'a guère de sens...
Du point de vue de l'analyse et de la conception, le problème est
légèrement différent. L'analyse consiste essentiellement (du moins pour
la partie qui nous intéresse ici) à modéliser le domaine (le problème à
résoudre). A ce stade, on a essentiellement - dans un premier temps du
moins - des représentations pratiquement 1 pour 1 d'éléments "concrets"
(ie client, produit, commande, facture etc). Attention, j'ai bien parlé
de *représentations* - il ne s'agit pas de modéliser fidèlement
l'élément réel (une personne par exemple), mais de se concentrer sur ce
qui fait sens dans le cadre du problème à résoudre (bref, de modéliser
l'élément *tel qu'il est vu par le système*, et non tel qu'il est
réellement - ce qui serait de toutes façons impossible).
En général, l'analyse détaillée tend à introduire un premier niveau
d'abstraction, en refactorisant les définitions obtenues lors de la
phase préalable afin d'obtenir un ensemble aussi cohérent que possible.
Cette phase commence à faire apparaître des objets qui relèvent plus de
la solution (système informatique) que du problème (système
d'information), comme par exemple des classes de base etc... Arrivé à la
conception (formulation de la solution), on voit apparaître une
multitude d'objets sans aucun rapport avec le domaine (objets
techniques, par opposition aux objets "métier" issus de l'analyse) - et
parfois même on voit les objets métier disparaître purement et
simplement (dans beaucoup d'applications de gestion, la multiplicité et
la complexité des relations entre les entités métier et des différentes
"vues" nécessaires entraine l'utilisation du modèle relationel, et
l'application ne voit plus que des des requêtes et des relations). Ce
qui n'empêche pas l'utilisation du modèle objet : une table, une requête
SQL etc peuvent eux-même être représentés comme des objets.
En tout état de cause, l'essentiel est de bien capturer les
responsabilités des différents objets et les relations qui les unissent.
L'implémentation en découle. Et de ne pas se tromper de granularité
selon les différentes phases.
HTH