Smalltalk et IoC

Question

Je vois beaucoup de frameworks IoC pour .Net et Java. Est-ce que quelqu'un sait pourquoi il n'y a pas de cadres équivalents pour Smalltalk? C'est plus une question de philosophie que toute autre chose. Je me demande s'il y a quelque chose dans la façon de faire de Smalltalk qui exclut la nécessité d'avoir un cadre IoC.

Answer 1

MVC a été inventé sur Smalltalk et est sans doute le cadre original Inversion of Control. Bien qu'un peu plus léger que ses homologues Java, il a les concepts de base d'un modèle contenant les données, une vue rendant les données en réponse à des événements propagés à partir d'un contrôleur.

De manière moins flagrante, Java a en réalité besoin de beaucoup de prise en charge de l'infrastructure pour créer une application Web sans quantités excessives de code standard. Smalltalk prend en charge les idiomes de programmation tels que continuations, qui permettent à un auteur de prétendre qu'il n'écrit pas vraiment de code piloté par les événements. Seaside fonctionne comme ceci, donnant les avantages d'IoC avec un paradigme de développement quelque peu plus flexible.

EDIT: MVC est un framework pour les interfaces utilisateur dans Smalltalk (on peut dire que ce n'est pas vraiment un framework en tant que tel, mais la bibliothèque de classes l'a intégré). Il a l'inversion de propriété de contrôle en ce que la vue et le modèle répondent aux événements envoyés par le contrôleur - le ne nous appelle pas, nous vous appellerons la propriété. Inversion of Control est un modèle de conception dans les frameworks qui est utilisé pour réduire le besoin d'une extension étendue dans les applications Java. Dans certaines définitions d'un framework d'application, Inversion of Control est la propriété principale considérée comme distinguant un framework d'une bibliothèque.

Answer 2

Les fonctions sont des citoyens de première classe dans smalltalk, il est donc facile d'avoir IoC sans cadre.

Answer 3

Je pense que l'IOC ou le modèle d'injection de dépendances résout un problème qui n'existe pas vraiment dans l'environnement Smalltalk. Smalltalk est un langage dynamique non typé et utilise le passage de message pour communiquer. Cela fait pour les objets qui sont faiblement couplés par la nature au niveau de la langue. Tout objet peut envoyer un message à un autre objet sans tenir compte du type tant qu'il peut traiter le message. Donc, comme vous pouvez le deviner, le changement des dépendances à un moment donné est relativement facile et naturel. Il suffit de décider où, quand et comment vous voulez changer la dépendance.

Answer 4

Voici quelques raisons possibles. La première est que nous n'avons pas pris la peine d'utiliser le qualificatif «IoC», qui est essentiellement redondant - puisque appeler quelque chose un cadre implique l'inversion du flux de contrôle.

Un autre est que le langage Smalltalk fournit un support direct pour les flux "IoC" - sous la forme de fermetures. Un des résultats de la programmation avec des fermetures est que le flux de contrôle tel qu'il se trouve dans les cadres ne semble pas si nettement différent qu'il évoque le sentiment d'être "inversé" d'un sens "normal" de flux; plutôt, avec des fermetures, le flux de contrôle oscille entre ces deux perspectives tout le temps, et partout. Même dans des déclarations uniques. Une troisième raison, peut-être, est que, même sans fermeture, l'inversion de contrôle décrite n'est pas uniquement associée aux frameworks - les mêmes flux se retrouvent dans la plupart des formes de code impliquant des E/S. Quatrièmement, les Smalltalkers utilisent probablement ce type de flux plus encore que les autres, car nous nous appuyons plus sur les notions d'objets et de messages échangés entre eux que sur les notions de structures et d'appel de fonctions membres. En l'absence de fermetures, ces deux vues sont équivalentes, et interchangeables, mais l'ajout de fermetures change le résultat - le sens du flux de contrôle utilisé en est l'un des effets.Enfin, on pourrait même penser à décrire le style de contrôle du REPL comme un sens «plus simple», mais «inversé» du flux «normal», normal dans le sens où il est utilisé presque partout ailleurs. En résumé, les mêmes types d'infrastructure existent pour Smalltalk. Nous les décrivons un peu différemment, c'est tout. La différence est, au moins en partie, due à la présence et l'utilisation des fermetures dans Smalltalk, que de nombreux autres environnements ne fournissent pas encore - - notamment C++, C# et Java.

Answer 5

En Java une dépendance est créé lorsque vous écrivez quelque chose comme

MyClass32 temp = this.theThing();

Maintenant, votre code DEPEND de la classe MyClass32 étant autour. Votre code ne fonctionnera pas sans elle. Tout changement dans cette classe peut rendre votre code incompilable, nécessitant un beaucoup de changements supplémentaires dans votre code, qui peut exiger d'autres changements de code dans la classe qui dépendent de la vôtre. Beaucoup de travail supplémentaire. Dans Smalltalk, vous écrirez temp: = self theThing; Votre code fonctionnera peu importe ce qui est retourné par #getTheThing. Votre code n'est pas dépendant sur la classe MyClass32 étant autour. Votre seule dépendance est que 'temp' doit comprendre tous les messages que vous lui envoyez . Donc, dans un sens, le but de Dependency Injection Frameworks est de faire un langage à typage statique comme Java fonctionne plus comme un dy7namically typé. Cela dit, il y a un MOTIF DE CONCEPTION J'ai souvent suivi dans Smalltalk: Créer une méthode de classe comme MyClass qui renvoie QUELQUE classe. Il n'a pas besoin de le nom "MyCLass". Il pourrait s'agir de l'une des classes , retournant une classe différente la nuit. Ce modèle est présent dans Smalltalk MVC, où View-classes a la méthode #defaultControllerClass, qui est généralement redéfinie par les sous-classes.