Inversion of Control est-il spécifique aux langues OO?

Question

Une autre façon de poser cette question est la suivante: qu’est-ce que Inversion of Control?

Je pose cette question car l'article de Wikipedia sur IoC a été piraté par un non-OO explication. Cette information provient de la page de discussion et date de 2007:

  

J'ai pris la liberté de réécrire complètement la page, le contenu précédent ayant été complètement repris par un message sans signification "orienté objet". babiller ...

Je ne vois pas en quoi Inversion of Control aurait un sens en dehors du langage OO. Il existe déjà de nombreuses explications pour abandonner le contrôle dans les langages procéduraux (la programmation d'événements en est une) et les langages purement fonctionnels n'ont pas besoin d'un concept comme Inversion of Control car ils ont des fonctions d'ordre supérieur.

De même, dans le article , où Martin Fowler donne des détails sur l'IoC, il traite exclusivement des exemples OO.

Donc, IoC est-il exclusivement un concept OO, et en quoi consiste-t-il exactement?

Pour moi, IoC essaie de transformer des fonctions en données dans les limites imposées par la plupart des langages orientés objet et essaie de transmettre ces fonctions en tant que données en tant qu'arguments à d'autres fonctions. Ce n'est pas la seule partie d'IoC, mais il y a une partie de cela.

Il existe également le modèle de conception d'usine, dans lequel des arbres d'objets sont en cours de construction et de configuration avant d'être transmis.

Pour moi, IoC est exclusivement un concept OO.

Quelle est votre réponse?

Answer 1

Vous examinez le problème théorique du point de vue de la mise en œuvre. La première question qui se pose devrait être le contrôle exact que vous inversez ?

Ensuite, vous vous rendrez compte que ce n'est pas grave si c'est un objet, une méthode, une fonction ou quoi que ce soit qui est passé autour, mais ce que le code fait réellement.

En résumé, lorsque vous effectuez une injection de dépendance, vous inversez le contrôle de la création et de l'utilisation de dépendances (de ressources).

Lorsque vous attribuez un pointeur à une fonction de rappel à une fonction API Windows, vous lui donnez le contrôle d'appeler votre fonction avec ses propres paramètres.

Vous voyez donc que l'IoC n'est qu'un concept théorique et qu'il peut bien entendu y avoir différentes implémentations pratiques.

Answer 2

L'inversion de contrôle n'est certainement pas un concept d'OO.

IoC existe et est utilisé assez fréquemment dans des langages non-OO. C'est très courant en C, par exemple. L’API Windows en est un excellent exemple. Chaque fois que vous appelez une fonction de l’API Windows fonctionnant via des rappels, vous utilisez essentiellement IoC sous sa forme la plus primitive.

Par exemple, consultez la fonction EnumWindows . En utilisant cela, vous passez un pointeur de fonction (EnumWindowsProc) à une bibliothèque et votre code est exécuté depuis le code de la bibliothèque.

Comparez cela à la définition de l'inversion du contrôle de Wikipedia: "L'inversion du contrôle se produit lorsqu'une procédure de bibliothèque appelle une ou plusieurs procédures utilisateur."

C'est exactement la même chose.

Cependant, IoC devient vraiment très puissant, flexible et facile à utiliser lorsque vous ajoutez un système de types riche et de nombreux autres outils fournis avec la POO. Cela le rend plus courant, car il est "plus agréable". travailler avec, mais il existait avant la POO.

Answer 3

Le concept d ’" inversion du contrôle " semble applicable partout où vous avez un moyen de faire passer les pointeurs de fonction. Fondamentalement, les concepts de plug-in et les DLL avec des signatures compatibles (pensez aux pilotes, par exemple) ne sont rien d'autre qu'une forme d'IoC.

Toutefois, lorsque vous utilisez IoC avec un modèle de type riche et de conteneur, vous vous retrouverez automatiquement dans le monde OO. Et les concepts de POO correspondent très bien aux concepts d'IoC, en particulier dans les langages prenant en charge l'héritage multiple avec des classes virtuelles pures (ou "interfaces", comme on les appelle également).

Answer 4

En fait, la mise en œuvre de l'IoO par OO est assez complexe, car les fonctions ne sont souvent pas des citoyens de première classe.

Comme Azder l’a mentionné: IoC est utilisé pour de nombreuses raisons. Je vais en résumer quelques unes ici pour convaincre:)

Itération

#ruby
{1,2,3}.each{ |i| puts i }

#haskell
map [1,2,3] ( \i -> write i )

//the stl algorithms
int printint( int i ){ return printf( "%d", i ); }
std::foreach( onetwothree.begin(), onetwothree.end(), &printi );

Création de threads

CreateThread( NULL, 0, &myFunction, NULL, 0, NULL );

Répartition générale des événements

//javascript
document.getElementById( "mybutton" )
            .addEventListener( 
                 function(e){ alert("buttonPressed") } );

Aucun de ces exemples n'est orienté objet, q.e.d ..