Principes pragmatiques de conception objet
nucleus
Membre
La programmation orientée objet (POO) implique la connaissance de nombreux concepts (héritage/spécialisation, polymorphisme, encapsulation..)
Mais il n'est pas forcement facile et évident de trouver l'équilibre dans leur usage, de ne pas en abuser ou de ne pas en faire assez.. donc de ne perdre en souplesse, et finalement de ne pas profiter des réels avantages de l'objet (maintenabilité, réutilisabilité..)
Voici quelques principes à garder en tête lors de la conception objet:
Ne pas se répéter
Tout concept/élément modélisé doit avoir une seule et une seule représentation non ambiguë et reconnue en tant que telle par tous dans le système modélisé.
Tout changement doit pouvoir se faire à un seul endroit.
Bien sûr ce n'est pas toujours possible à première vue, mais on peut toujours s'arranger (par exemple, en générant automatiquement du code à partir d'une source unique)
Rester réservé
Un objet ne devrait pas trop se révéler aux autre, et se mêler des affaires des autres.
Autrement il y a une augmentation des risques de couplages statiques (dépendances nécessaire à la compilation), dynamiques (dépendances nécessaires au démarrage), temporelles (dépendant d'un ordre précis dans l'exécution, à un moment précis ou en même temps que quelque chose d'autre) et fonctionnelles (nécessaire du point de vue de l'utilisateur)..
Ex: ne pas abuser de l'héritage (et des catégories en objective-C), bien souvent la délégation est plus souple et efficace.. Si A hérite de B, cela doit seulement signifier que A est une sorte de B, mais surtout pas A possède un B ou A utilise un B. D'ailleurs je préfère le terme spécialisation au terme héritage..
Déclarer plutôt que demander
Il faut partir du principe qu'il faut dire aux objets ce que vous voulez qu'il fassent, et non pas leur poser des questions sur leur état, puis prendre une décision, pour finir par leur dire comment s'y conformer (approche plutôt procédurale)..
Le problème, c'est que la logique de la prise de décision est probablement plutôt de la responsabilité de l'objet appelé, et non pas de l'objet appelant..
Pour éviter cela, il vaut mieux concevoir les classes en termes de responsabilités, puis de définir pour chaque classe des commandes plutôt que des requêtes..
Mais il n'est pas forcement facile et évident de trouver l'équilibre dans leur usage, de ne pas en abuser ou de ne pas en faire assez.. donc de ne perdre en souplesse, et finalement de ne pas profiter des réels avantages de l'objet (maintenabilité, réutilisabilité..)
Voici quelques principes à garder en tête lors de la conception objet:
Ne pas se répéter
Tout concept/élément modélisé doit avoir une seule et une seule représentation non ambiguë et reconnue en tant que telle par tous dans le système modélisé.
Tout changement doit pouvoir se faire à un seul endroit.
Bien sûr ce n'est pas toujours possible à première vue, mais on peut toujours s'arranger (par exemple, en générant automatiquement du code à partir d'une source unique)
Rester réservé
Un objet ne devrait pas trop se révéler aux autre, et se mêler des affaires des autres.
Autrement il y a une augmentation des risques de couplages statiques (dépendances nécessaire à la compilation), dynamiques (dépendances nécessaires au démarrage), temporelles (dépendant d'un ordre précis dans l'exécution, à un moment précis ou en même temps que quelque chose d'autre) et fonctionnelles (nécessaire du point de vue de l'utilisateur)..
Ex: ne pas abuser de l'héritage (et des catégories en objective-C), bien souvent la délégation est plus souple et efficace.. Si A hérite de B, cela doit seulement signifier que A est une sorte de B, mais surtout pas A possède un B ou A utilise un B. D'ailleurs je préfère le terme spécialisation au terme héritage..
Déclarer plutôt que demander
Il faut partir du principe qu'il faut dire aux objets ce que vous voulez qu'il fassent, et non pas leur poser des questions sur leur état, puis prendre une décision, pour finir par leur dire comment s'y conformer (approche plutôt procédurale)..
Le problème, c'est que la logique de la prise de décision est probablement plutôt de la responsabilité de l'objet appelé, et non pas de l'objet appelant..
Pour éviter cela, il vaut mieux concevoir les classes en termes de responsabilités, puis de définir pour chaque classe des commandes plutôt que des requêtes..
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
On parle aussi de composition, en C++ le multi héritage est la plupart du temps utilisé à tort, alors qu'en fait il s'agit simplement de créer un objet se composant de plusieurs autres. Néanmoins je regrette que ni java ni ObjC ne permettent le muti héritage, car c'est d'une souplesse incomparable, même s'il permet tous les abus.
Je n'y pensais plus mais c'est un fait que j'ai moi aussi eu le plus grand mal à admettre que l'on ne pouvait pas utiliser le multi héritage lorsque je suis passer à Obj-C.
Au début ça me semblait une grande lacune et m'a fait hésiter à adopter Cocoa.
De l'histoire ancienne maintenant
Tout à fait.. La délégation utilise la composition/aggrégation..
Le multi héritage d'interfaces/protocoles est tout de même possible en Java et en Objective-C..
Et combiné à l'usage de la délégation (et un IDE compatissant tel qu'Eclipse), on peut obtenir la même chose que le multi-héritage du C++ (interface+implémentation) sans les inconvénients tels que le "diamond of death" et les problèmes de compréhension de l'héritage virtuel..