Pragmatisme en conception objet

nucleusnucleus Membre
Un message que j'avais posté dans les bases et qui va bien içi.. :-)
--
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 ou la composition est plus souple et plus 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.