surcroma@gmail.com wrote:

fgirault@gmail.com a écrit :

surcroma@gmail.com wrote:
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.

le "plutôt" me gêne car un objet regroupe les deux à la fois.

Un objet est une instance d'une classe qui définie des attributs
(taille, couleur ...) et des méthodes (sonner, clignoter, changer de
chaîne ...).

Il peut "s'occuper" d'autres objets dans divers types de relation avec
ceux-ci : utilisation / délégation, aggrégation, composition ...

Bref, rien d'exclusif, tout dépend du contexte.

À question floue ... réponse vague ;)

Je n'ai peut être pas été très clair dans l'énoncé de ma
question. En fait en disant s'occupe de quelque chose, je voulais dire
ne s'occupe que de quelque chose et donc qu'un objet puisse directement
être assimilable à une fonction. Pour simplifier, est-ce qu'un objet
peut être dénué de cette "consistance" qui pourrait caractériser un
objet et remplir exactement le même rôle qu'une fonction, "être" une
fonction ?

Dans certains langages, les fonctions sont des objets, et il est
possible de créer soit même des objets se comportant comme des
fonctions. Dans les langages ne le permettant pas, on a créé le pattern
functor pour contourner cette limitation - ainsi que d'autres patterns
similaires (command, strategy...). Cela indique clairement, AMHA, qu'il
y a de réels cas d'utilisation pour des objets-fonctions...

En fait ma question se réfère à un cas  bien concret. Il s'agit d'un
programme faisant évoluer, graphiquement, des robots dans un même
espace. Ces robots possèdent un certain nombre de roues et ont bien
sûr la possibilité  de se déplacer, avec différents types de
déplacements (tourner à gauche, avancer etc.) Evidement un robot
ayant 2 roues n'avancera pas de la même manière qu'un robot en ayant
4 car le nombre de moteurs requis sera différent.
La problématique vient lors de la création des robots. Il faut en
effet les initialiser en leur spécifiant les déplacements qu'ils
seront amenés à effectuer. Je cherchais à savoir si l'idée de
créer des classes implémentant les déplacements (comme reculer,
demi-tour etc.) de ces robots était une bonne idée.

Bravo, tu viens de réinventer le pattern strategy !-)

Bien sûr il
faudra créer une classe différente pour chaque déplacement
correspondant à un nombre de roues (avancer_2_roues, avancer_4_roues
reculer_2_roues etc..). Lors de l'initialisation des robots, il
faudrait alors donner des instances de ces classes au constructeur (le
langage est le java) de la classe robot.
J'aimerai savoir si une telle solution est adaptée.

Dans l'idée générale, tout à fait.

Dans le détail, il peut éventuellement (difficile à dire sans connaitre
le détail du projet) être préférable de regrouper les différents actions
de déplacements dans une même classe, ie:

interface DeplacementRobot {
  public void avancer();
  public void reculer();
  // etc
}

class Deplacement4Roues implements DeplacementRobot {
   // ...
}

class Deplacement2Roues implements DeplacementRobot {
   // ...
}

etc...


--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"