Concepts de base de la programmation orientée objet

Temps de lecture10 min

En bref

Résumé de l’article

Une des étapes importantes et une des plus difficiles dans le développement d’un logiciel orienté objet est d’identifier l’ensemble de classes le plus pertinent qui permet de résoudre le problème donné. Pour cette activité, il n’y a pas vraiment de méthode systématique, il s’agit d’une activité plutôt créative mais les bases sont relativement simples.

Dans cet article, nous présentons quelques éléments qui peuvent vous guider dans cette activité.

Points clés

  • Identifier un ensemble de classes pertinent qui permet de résoudre un problème est une tâche difficile pour laquelle il n’y a pas de méthode systématique.

  • Il s’agit d’un processus itératif dans lequel, à chaque étape des classes candidates sont ajoutées et d’autres sont rejetées jusqu’à ce que l’ensemble se stabilise.

  • Pour guider le choix des classes à rejeter, il existe quelques signaux d’alerte à considérer.

Contenu de l’article

L’identification de l’ensemble de classes le plus pertinent pour répondre à un problème est un processus itératif : On démarre avec un ensemble de classes candidates puis on ajoute et on supprime jusqu’à ce que l’ensemble se stabilise.

Pour le premier ensemble de classes candidates, il n’y a pas de consensus sur une méthode qui permettrait de les identifier. Certains proposent de souligner les noms dans l’énoncé du problème et en faire des classes candidates. Mais,

  • cela donne parfois trop de classes (synonymes, concept de peu d’importance, etc.),
  • et parfois on oublie des classes importantes masquées par des tournures de style (verbe, pronom)

D’autres proposent de ne pas trop faire attention aux noms et d’identifier les éléments qui peuvent être importants pour résoudre le problème. La décision de ce qui est important ou non est prise à partir de l’énoncé du problème, de nos connaissances du domaine du problème posé, de notre expérience préalable, etc.

Une fois que la première série de classes a été identifiée, il faut se demander si elles sont toutes utiles et si certaines classes importantes n’ont pas été oubliées. Cela signifie deux choses : Comment trouver des classes candidates et comment démasquer celles qui sont inadéquates. Et ces deux aspects ne sont pas étudiés l’un après l’autre, ils sont constamment imbriqués.

Dans tous les cas, pour chaque classe candidate, il faut bien identifier quelles sont ses responsabilités (quels sont ses attributs/propriétés et ses méthodes), avec qui elle doit collaborer pour assurer ses responsabilités (associations) et les relations hiérarchiques entre les classes (héritage).

Quelques pistes pour l’identification des classes

Le processus d’identification de classes est donc une série d’activités pour trouver des classes candidates et pour rejeter celles qui ne sont pas pertinentes pour le problème posé. Pour vous aider dans cette identification, nous vous présentons ici quelques éléments qui peuvent vous aider à guider votre recherche.

Passons en revue ici quelques signes qui indiquent généralement un mauvais choix de classe. Mais attention, il ne faut pas considérer ces signes comme la preuve d’un mauvais choix de classe. Dans chaque cas, on peut penser à des circonstances qui peuvent rendre la décision initiale légitime. Il ne s’agit donc pas de négations absolues, mais de négations indicatives, de signaux de danger qui vous avertissent de la présence d’un modèle suspect et qui doivent vous inciter à approfondir vos recherches.

Ma classe fait …

Pour une classe donnée, posez-vous la question : Quel est le rôle de la classe ? Si la réponse est cette classe imprime les résultats… ou cette classe analyse l’entrée de… ou de manière générale cette classe fait … cela peut mettre en évidence une classe qui n’est pas censée en être une.

En fait, une classe n’est pas censée faire une seule chose, mais offrir un certain nombre de services (méthodes). Si elle ne fait vraiment qu’une seule chose, il s’agit probablement d’une erreur, c’est-à-dire une classe pour ce qui ne devrait être qu’une méthode d’une autre classe.

Noms impératifs

Si le nom d’une classe candidate est un verbe à l’impératif ou à l’infinitif, il doit attirer votre attention comme signalant un cas probable de classe qui ne devrait pas en être une. Il peut arriver que la classe soit pertinente mais dans ce cas, son nom est erroné. En règle générale, le nom d’une classe doit être un nom, éventuellement qualifié. Cela permet d’appliquer le principe selon lequel chaque classe représente une abstraction logicielle avec un état et un comportement.

Plusieurs abstractions pour une classe

Un autre signe d’une classe qui n’en est pas une est le fait qu’elle représente plus qu’une seule abstraction. Les responsabilités (attributs et méthodes) attribuées à une classe donnée doivent toutes être liées à la même abstraction clairement identifiée.

Pour aller plus loin

  • Object Design. Roles, Responsibilities, and Collaborations, Rebecca Wirfs-Brock, Alan McKean. Addison-Wesley, 2003.

    Identification de classes en utilisant les CRC Cards.

  • Object-Oriented Software Construction. 2nd edition, Bertrand Meyer. Prentice Hall PTR, 1997.

Pour aller au delà

Un langage de modélisation de logiciels