Smalltalk和IoC

Question

我看到很多用於.Net和Java的IoC框架。 有誰知道為什么沒有Smalltalk的等效框架。 這是一個哲學問題，而不是其他任何問題。 我想知道Smalltalk的做法是否有一些事情可以排除擁有IoC框架的必要性。

Answer 1

MVC是在Smalltalk上發明的，可以說是最初的Inversion of Control框架。 雖然比java對應物更輕巧，但它具有保存數據的模型的基本概念，一個視圖呈現數據以響應從控制器傳播的事件。

不那么輕率，Java實際上需要大量的框架支持才能完成Web應用程序，而無需過多的樣板代碼。 Smalltalk支持編程習慣，例如continuation ，它允許作者假裝他們並沒有真正編寫事件驅動的代碼。 Seaside就是這樣的，它給IoC帶來了一些更靈活的開發范例。

編輯：MVC是Smalltalk中UI的框架（可以說它不是真正的框架，但是類庫已經內置了對它的支持）。 它具有控制屬性的反轉，因為視圖和模型響應控制器調度的事件 - 不要打電話給我們，我們稱之為屬性。 控制反轉是框架內的一種設計模式，用於減少Java應用程序中廣泛樣板的需求。 在應用程序框架的某些定義中，控制反轉是主要屬性，被視為區分框架和庫。

Answer 2

函數是smalltalk中的一等公民，所以沒有框架就很容易擁有IoC。

Answer 3

我認為IOC或依賴注入模式解決了Smalltalk環境中並不存在的問題。 Smalltalk是一種無類型的動態語言，使用消息傳遞進行通信。 這使得在語言級別上自然松散耦合的對象成為可能。 只要可以處理消息，任何對象都可以將消息發送到另一個對象而不考慮該類型。 因此，您可能會猜測在任何給定時間更改依賴關系都相對容易且自然。 只需要決定改變依賴關系的位置，時間和方式。

Answer 4

在Java中，當您編寫類似的內容時會創建依賴關系

MyClass32 temp = this.theThing（）;

現在你的代碼在MyClass32類的DEPENDS周圍了。 沒有它，您的代碼將無法運行。 該類中的任何更改都可能使您的代碼無法編譯，需要對代碼進行大量額外更改，這可能需要在類中進一步依賴於您的代碼更改。 很多額外的工作。

在Smalltalk你會寫temp：= self theThing;

無論#getTheThing返回什么，您的代碼都會正常工作。 您的代碼不依賴於MyClass32類。 你唯一的依賴是'temp'必須理解你發送給它的任何消息。

因此從某種意義上說，依賴注入框架的目的是使像Java這樣的靜態類型語言更像是一個動態類型的語言。

也就是說，我經常在Smalltalk中遵循一個設計模式：創建一個類似於MyClass的類方法，返回SOME類。 它不需要名稱'MyCLass'。 它可能是幾個班級中的一個，晚上回到不同的班級。 這種模式存在於Smalltalk MVC中，其中View-classes具有方法#defaultControllerClass，該方法通常由子類重新定義。

Answer 5

一些可能的原因。 一個是我們沒有費心使用“IoC”限定符，這實際上是多余的 - 因為調用某個框架意味着控制流的反轉。

另一個是Smalltalk語言以閉包的形式為“IoC”流提供直接支持。 使用閉包進行編程的一個結果是，框架中的控制流似乎沒有那么明顯不同，以至於從“正常”的流動感中喚起“倒置”的感覺; 相反，對於封閉，控制流一直在這兩個視角之間來回翻轉，無處不在。 甚至在單一陳述中。

第三個原因可能是，即使沒有閉包，所描述的“控制反轉”也不是唯一與框架相關聯的 - 在涉及I / O的大多數形式的代碼中都可以找到相同的流程。

第四，Smalltalkers可能比其他人更多地使用這些流量，因為我們更多地依賴於對象的概念和它們之間發送的消息，而不是結構的概念和成員函數的調用。 在沒有閉包的情況下，這兩個視圖是等效的，並且可以互換，但是閉包的添加改變了結果 - 使用中的控制流感是其中一個效果。

最后，人們甚至可以考慮將控制流的REPL風格描述為“更簡單”，但“倒”意義上的“正常”流，正常意義上它幾乎用於其他任何地方。

總之，Smalltalk存在相同類型的框架。 我們描述它們的方式有點不同。 不同之處在於，至少部分是由於Smalltalk中存在和使用了閉包，許多其他環境尚未提供 - 特別是C ++，C＃和Java。