我看到很多用于.Net和Java的IoC框架。有谁知道为什么没有Smalltalk的等效框架。这是一个哲学问题,而不是其他任何问题。我想知道Smalltalk的做法是否有一些事情可以排除有必要建立IoC框架。

有帮助吗?

解决方案

MVC 是在Smalltalk上发明的,可以说是原来的反转控制框架。虽然比java对应物更轻巧,但它具有保存数据的模型的基本概念,一个视图呈现数据以响应从控制器传播的事件。

不那么轻率,Java实际上需要大量的框架支持来完成Web应用程序而不需要过多的样板代码。 Smalltalk支持编程习惯用法,例如延续,允许作者假装他们没有真正写作事件驱动代码。 Seaside 的工作方式与此类似,通过更灵活的开发范式提供IoC的优势

编辑:MVC是Smalltalk中UI的框架(可以说它不是真正的框架,但是类库已经内置了对它的支持)。它具有控制属性的反转,因为视图和模型响应控制器调度的事件 - 不要打电话给我们,我们称之为属性。控制反转是框架内的一种设计模式,用于减少Java应用程序中广泛样板的需求。在应用程序框架的某些定义中,Inversion of Control是主要属性,被视为区分框架和库。

其他提示

函数是smalltalk中的一等公民,所以没有框架就很容易拥有IoC。

我认为IOC或依赖注入模式解决了Smalltalk环境中并不存在的问题。 Smalltalk是一种无类型的动态语言,使用消息传递进行通信。这使得在语言级别上自然松散耦合的对象成为可能。只要可以处理消息,任何对象都可以将消息发送到另一个对象而不考虑该类型。因此,您可能会猜测在任何给定时间更改依赖关系都相对容易且自然。只需要决定改变依赖关系的位置,时间和方式。

有几个可能的原因。一个是我们没有费心去使用“IoC”。限定符,本质上是多余的 - 因为调用某个框架意味着控制流的反转。

另一个原因是Smalltalk语言为“IoC”提供直接支持。流动 - 以封闭的形式。使用闭包进行编程的一个结果是,框架中发现的控制流似乎没有那么明显不同,以至于引起“倒置”的感觉。来自“正常”的流动感;相反,对于封闭,控制流一直在这两个视角之间来回翻转。即使在单一陈述中也是如此。

第三个原因可能是,即使没有封闭,“控制倒置”也是如此。被描述并不是唯一与框架相关联的 - 在大多数涉及I / O的代码中都可以找到相同的流程。

第四,Smalltalkers可能比其他人更多地使用这些流,因为我们更多地依赖于对象的概念和它们之间发送的消息,而不是结构的概念和成员函数的调用。在没有闭包的情况下,这两个视图是等效的,并且可以互换,但是闭包的添加会改变结果 - 使用中的控制流感是其中一种效果。

最后,人们甚至可以考虑将控制流的REPL样式描述为“更简单”,但是“反转”。感觉“正常”流量,在几乎所有其他地方使用的意义上是正常的。

总之,Smalltalk存在相同类型的框架。 我们描述它们的方式有点不同。 不同之处至少部分是由于存在和利用 Smalltalk中的闭包,许多其他环境尚未提供 - - 特别是C ++,C#和Java。

在Java中,编写时会创建依赖关系

之类的东西

MyClass32 temp = this.theThing();

现在您的代码在MyClass32类上取消 在身边。你的代码不起作用 没有它。该课程的任何变化都可以 使您的代码无法编译,需要一个 你的代码中有很多额外的变化 可能需要在课堂上进一步修改代码 这取决于你的。很多额外的工作。

在Smalltalk你会写   temp:= self theThing;

无论返回什么内容,您的代码都能正常运行 通过#getTheThing。您的代码不依赖 在MyClass32类周围。你唯一的 依赖性是'临时'必须理解的东西 您发送给它的消息。

从某种意义上说,依赖注入的目的 框架是制作静态类型语言 就像Java工作更像是一个dy7namically类型的。

那就是说,我经常有一个设计模式 在Smalltalk中跟随:创建一个类方法 返回SOME类的MyClass。它不需要 名称'MyCLass'。它可能是其中之一 上课,晚上回到不同的班级。 这种模式存在于Smalltalk MVC中, 其中View-classes的方法是#defaultControllerClass, 通常由子类重新定义。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top