interface DeplacementRobot {
public void avancer();
public void reculer();
// etc
C'est le design pattern "Stratégie".
Pour le contributeur à l'origine de ce thread ("surcroma") je recommande
la lecture du livre "Design Patterns Tête La Première". Il est éclairant
sur ces tactiques indispensables en conception objet.
class Deplacement4Roues implements DeplacementRobot {
// ...
Je me demande si on peut faire mieux pour le nommage des classes
dérivées de "DeplacementRobot". (Je ne dis pas que c'est mauvais,
simplement une intuition qu'il pourrait y avoir mieux.)
La question d'origine de "surcroma" ressemble à une question de philo,
mais en fait il faut la comprendre comme une (bonne) question sur le
*nommage* des classes.
Le nommage est important parce que bien nommer les choses, c'est un
prérequis à être capable de bien en parler, c'est à dire d'en parler
avec précision, simplicité et brièveté. D'ailleurs il n'y a pas que les
classes qui sont concernées, mais toutes les "parties du discours" -
méthodes, constantes, etc.
Par exemple, le nom d'une classe est (sauf cas exceptionnels) un
substantif singulier. Jamais (autant que je me souvienne) un verbe; ce
sont les méthodes qui sont les verbes. Une interface peut être nommée
d'un substantif singulier ou d'un adjectif, le plus souvent en "able",
par exemple "Observable".
La question à poser quand on voit le nom d'une classe est: ce nom
renseigne-t-il de façon efficace sur ce que sont les *responsabilités*
de l'objet en question ?
C'est avec cette question qu'on peut écarter comme "mauvais" une classe
qui s'appellerait "GestionnaireDeRobots". Que doit "gérer", exactement
ce gestionnaire ? Ca peut être tout et n'importe quoi.
Avec quoi est-ce qu'un robot avance ? Avec un bloc moteur. D'ailleurs un
robot qui n'est pas doté d'un bloc moteur n'avancera pas. Une classe
abstraite nommée BlocMoteur (avec des variétés comme
BlocMoteurTroisRoues ou BlocMoteursQuatreRoues ou même BlocMoteurHelice)
renseigne mieux sur les responsabilités qu'elle encapsule.
Laurent
