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 framework équivalent pour Smalltalk? C'est plus une question de philosophie qu'autre chose. Je me demande s’il existe quelque chose dans la manière de faire Smalltalk qui exclut la nécessité d’avoir un framework IoC.

Answer 1

MVC a été inventé sur Smalltalk et est sans doute l'original Inversion of Control . Un peu plus léger que ses équivalents java, il présente 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 par un contrôleur.

De façon moins flagrante, Java nécessite en réalité beaucoup de prise en charge de la structure pour réaliser une application Web sans utiliser une quantité excessive de code standard. Smalltalk prend en charge les idiomes de programmation tels que continuations , qui permettent à l'auteur de prétendre qu'il ne s'agit pas d'un événement en cours d'écriture. code conduit. Seaside fonctionne de la sorte, offrant ainsi les avantages d'IoC avec un paradigme de développement légèrement plus souple. .

EDIT: MVC est un cadre pour les interfaces utilisateur dans Smalltalk (ce n’est peut-être pas vraiment un cadre en tant que tel, mais la bibliothèque de classes l’a supporté). Il possède l'inversion de la propriété control en ce que la vue et le modèle répondent aux événements envoyés par le contrôleur - ne nous appelez pas, nous vous appellerons propriété. Inversion of Control est un modèle de conception au sein de structures qui permet de réduire le recours à une plate-forme é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 en petit-parler, il est donc facile d'avoir IoC sans framework.

Answer 3

Je pense que IOC ou le modèle d’injection de dépendance résout un problème qui n’existe pas vraiment dans l’environnement Smalltalk. Smalltalk est un langage dynamique non typé qui utilise la transmission de messages pour communiquer. Cela crée des objets faiblement couplés par nature au niveau du langage. N'importe quel objet peut envoyer un message à un autre objet sans égard au type tant qu'il peut traiter le message. Donc, comme vous pouvez le deviner, changer de dépendance à un moment donné est relativement facile et naturel. Il suffit de décider où, quand et comment vous souhaitez modifier la dépendance.

Answer 4

Quelques raisons possibles à cela. La première est que nous n’avons pas pris la peine d’utiliser le " IoC " qualificatif, qui est essentiellement redondant - car appeler quelque chose un cadre implique l'inversion du flux de contrôle.

Un autre problème est que le langage Smalltalk fournit une prise en charge directe de "IoC". flux - sous la forme de fermetures. Un des résultats de la programmation avec des fermetures est que le flux de contrôle, tel qu'on le trouve dans les cadres, ne semble pas tellement différent au point de donner l'impression d'être "inversé". à partir d'un " normal " sens de l'écoulement; Au contraire, avec les fermetures, le flux de contrôle va et vient entre ces deux perspectives tout le temps et partout. Même dans les déclarations simples.

Une troisième raison, peut-être, est que, même sans fermeture, le "renversement du contrôle" Cette description 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 encore plus que d’autres, car nous nous appuyons davantage 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 modifie le résultat: le sens du contrôle en cours d'utilisation est l'un des effets.

Enfin, on pourrait même penser à décrire le style de contrôle de flux REPL comme un "plus simple", mais "inversé". sens de la "normale" flow, normal dans le sens où il est utilisé presque partout ailleurs.

En résumé, les mêmes types de frameworks existent pour Smalltalk. Nous les décrivons un peu différemment, c'est tout. La différence tient, du moins en partie, à la présence et à l'utilisation des fermetures en Smalltalk, que de nombreux autres environnements ne fournissent pas encore - - notamment C ++, C # et Java.

Answer 5

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

MyClass32 temp = this.theThing ();

Maintenant votre code DÉPEND de la classe MyClass32 être autour. Votre code ne fonctionnera pas sans ça. Tout changement dans cette classe peut rendre votre code non compilable, nécessitant une beaucoup de changements supplémentaires dans votre code, qui peut nécessiter d'autres changements de code en classe cela dépend de la vôtre. Beaucoup de travail supplémentaire.

En Smalltalk, vous écririez   temp: = self theThing;

Votre code fonctionnera quel que soit le retour par #getTheThing. Votre code n'est pas dépendant sur la classe MyClass32 étant autour. Votre seul la dépendance est que 'temp' doit comprendre tout messages que vous lui envoyez.

Donc, dans un sens, le but de l’injection de dépendance Frameworks est de faire un langage statiquement typé comme Java fonctionne plus comme un dy7namically typé.

Cela dit, il existe un MOTIF DE CONCEPTION que j'ai souvent suivi dans Smalltalk: Créer une méthode de classe comme MyClass qui retourne une classe. Il n'a pas besoin d'avoir le NOM 'MyCLass'. Ce pourrait être un de plusieurs cours, en retournant un cours différent le soir. Ce modèle est présent dans le Smalltalk MVC, où les classes View ont la méthode #defaultControllerClass, qui est généralement redéfini par les sous-classes.