Discussion:Inversion de contrôle

Terme 'implanter'

'Implémenter une interface' semble plus admis que 'implanter une interface'.

Le débat à déjà lieu sur Discuter:Implémentation et il n'y a pas encore d'entrée correspondante pour ce verbe dans le wikitionnaire. Cordialement, MistWiz 15 novembre 2006 à 20:20 (CET)

Principe de l'inversion des dépendances

"La solution consiste à créer, par exemple, un objet b de type B et de l'injecter dans un objet de type A."

Mais à partir du moment où il faut réinjecter dans A un objet de type B, on perpétue la dépendance. La dépendance n'est pas le fait de la syntaxe, et ne peut se résoudre avec de la syntaxe. Si A est dépendant de B, ce n'est pas le fait de déclarer une interface (comme Java le propose) qui va lever cette dépendance. Il me semble que la dépendance vient du modèle. On a conçu, délibérement ou non, un modèle dans lequel A dépend de B.

Ce n'est qu'en redéfinissant complètement ce qu'est un objet A et ce qu'est un objet B que l'on pourra (peut-être) lever cette dépendance.

A mon humble avis...

---

Si, le fait de passer par une interface lève bien la dépendance puisque l'on pourra à l'exécution (avec le mécanisme qui va bien) fournir n'importe quel objet pour la satisfaire pour peu que sa classe implémente la-dite interface. Lorsque j'écris ma classe référençante, je peux la compiler sans qu'aucune classe ne soit encore écrite pour satisfaire le service qu'elle exige et que définit l'interface. Je suis donc bien complètement indépendant. C'est le principe même de l'interface. Ce n'est pas une modif de syntaxe mais d'architecture du code.

--Patrice Ongla (d) 11 juin 2009 à 01:16 (CEST)

"Cadriciel" ?

Je pense qu'il ne faut pas exagérer : Utilisez le mot "Cadriciel" dans une DSI et observez la réaction des personnes autour de vous.
Je propose la suppression de cette expression de l'article.

Inversion ou pas inversion ?

J'essaie de clarifier ma compréhension du concept et j'ai un peu de mal. En fait j'ai l'impression que dans la littérature il a deux sens :

• l'inversion de contrôle proprement dite. Il me semble que c'est celle qui est à l'oeuvre basiquement depuis longtemps dans la programmation évennementielle par exemple. Je m'abonne aux évennements d'un objet (dont la classe peut venir d'un autre binaire) et je les traite (Addhandler et delegate en .Net). L'objet ne sait pas qui s'occupe de lui et ne demande rien (A ceci près que dans le cas de la prog évennementielle, l'architecture ne garantit pas que qqun écoute, l'objet ne sait pas si l'on s'occupe de lui). C'est bien le principe d'Holywood me semble-t-il (on n'est d'ailleurs pas sûr d'être rappelé :).
• Le couplage lâche des binaires via :

1. La substitution de référence à des classe "dures" par des interfaces.
2. Un mécanisme de résolution à l'exécution des instance effectives des objets à référencer (injection de dependance, ou service locator).

Dans le second cas, il n'y a pas à mon sens d'"inversion de contrôle" à proprement parler. Il n'y a pas de modification du flot de contrôle. La classe référençante peut toujours être initiatrice des appels et piloter complètement le traitement. La seule différence avec une situation classique c'est qu'elle ne sait pas quelle classe contrète exécute(ra) ses ordres. Mais c'est toujours elle qui les donne.

Il s'agit de deux problèmes d'architecture logicielle, mais le premièr relève de l'architecture logique (flot de contrôle), le second est d'avantage lié à des problématique de déploiement, de modularité et de testabilité.

L'article me semble hésiter entre les deux avec d'un côté l'explication qui est celle du 1)(principe d'Holywood) et de l'autre l'exemple d'implémentation (injection de dépendance) qui porte plutôt sur le 2).

Ca me paraît nécessiter une clarification.

--Patrice Ongla (d) 11 juin 2009 à 01:04 (CEST)

Avantages et inconvénients

L'article fait l'impasse sur les inconvénients de ce type d'approche, à savoir la compléxification du code. Cela me paraît pourtant important dans la mesure où on ne lit pas ce genre d'article seulement pour la culture mais aussi pour faire des choix.

La version anglaise est très claire pour sa part, et cette petiet phrase au moins mériterait d'être traduite : "A famous aphorism of David Wheeler goes: All problems in computer science can be solved by another level of indirection; this is often deliberately mis-quoted with "abstraction" substituted for "indirection". Kevlin Henney's corollary to this is, "...except for the problem of too many layers of indirection."'

Essentiel !

--Patrice Ongla (d) 11 juin 2009 à 01:09 (CEST)