Smalltalk e IoC

Question

Vedo molti framework IoC per .Net e Java. Qualcuno sa perché non ci sono framework equivalenti per Smalltalk. Questa è più una domanda filosofica che altro. Mi chiedo se c'è qualcosa nel modo Smalltalk di fare cose che precluda la necessità di avere un framework IoC.

Answer 1

MVC è stato inventato su Smalltalk ed è probabilmente l'originale Inversion of Control framework. Sebbene un po 'più leggero rispetto alle sue controparti Java, ha i concetti di base di un modello che contiene i dati, una vista che rende i dati in risposta a eventi propagandati da un controller.

Meno sorprendentemente, Java ha effettivamente bisogno di un sacco di supporto framework per fare un'applicazione web senza quantità eccessive di codice boilerplate. Smalltalk supporta idiomi di programmazione come continuazioni , che consentono a un autore di fingere di non scrivere realmente un evento codice guidato. Seaside funziona in questo modo, offrendo i vantaggi dell'IoC con un paradigma di sviluppo leggermente più flessibile .

EDIT: MVC è un framework per l'interfaccia utente in Smalltalk (probabilmente non è davvero un framework in quanto tale, ma la libreria di classi ha integrato il suo supporto). Ha l'inversione della proprietà di controllo in quanto la vista e il modello rispondono agli eventi inviati dal controller: non chiamarci, ti chiameremo proprietà. Inversion of Control è un modello di progettazione all'interno di framework che viene utilizzato per ridurre la necessità di un'estesa caldaia nelle applicazioni Java. In alcune definizioni di un framework applicativo, Inversion of Control è la proprietà principale che viene vista come distinzione di un framework da una libreria.

Answer 2

Le funzioni sono cittadini di prima classe in smalltalk, quindi è facile avere l'IoC senza un framework.

Answer 3

Penso che il CIO o il modello di Iniezione delle dipendenze risolva un problema che non esiste realmente nell'ambiente Smalltalk. Smalltalk è un linguaggio dinamico non tipizzato e utilizza i messaggi che passano per comunicare. Questo rende gli oggetti vagamente accoppiati dalla natura a livello linguistico. Qualsiasi oggetto può inviare un messaggio a un altro oggetto indipendentemente dal tipo, purché sia ??in grado di elaborare il messaggio. Quindi, come puoi immaginare, cambiare le dipendenze in un dato momento è relativamente semplice e naturale. Devi solo decidere dove, quando e come vuoi cambiare la dipendenza.

Answer 4

Alcuni possibili motivi per questo. Uno è che non ci siamo preoccupati di utilizzare il "quot" IoC " qualificatore, che è essenzialmente ridondante, poiché chiamare un framework implica l'inversione del flusso di controllo.

Un altro è che il linguaggio Smalltalk fornisce supporto diretto per " IoC " flussi - sotto forma di chiusure. Un risultato della programmazione con chiusure è che il flusso di controllo che si trova nei framework non sembra così nettamente diverso da evocare il senso di essere "invertito". da un "normale" senso di flusso; piuttosto, con le chiusure, il flusso di controllo si sposta continuamente avanti e indietro tra queste due prospettive, e ovunque. Anche all'interno di singole dichiarazioni.

Un terzo motivo, forse, è che, anche senza chiusure, l '"inversione del controllo" essere descritto non è associato in modo univoco ai framework: gli stessi flussi si trovano nella maggior parte delle forme di codice che coinvolgono l'I / O.

Quarto, i Smalltalker probabilmente usano questo tipo di flussi anche più di altri, poiché ci appoggiamo più pesantemente alle nozioni di oggetti e ai messaggi inviati tra loro piuttosto che alle nozioni di strutture e alla chiamata di funzioni membro. In assenza di chiusure, queste due viste sono equivalenti e intercambiabili, ma l'aggiunta di chiusure modifica il risultato: il senso del flusso di controllo in uso è uno degli effetti.

Infine, si potrebbe persino pensare di descrivere lo stile REPL del flusso di controllo come un "più semplice", ma "invertito" senso del "normale" flusso, normale nel senso che è usato quasi ovunque altro.

In sintesi, esistono gli stessi tipi di framework per Smalltalk. Li descriviamo in modo un po 'diverso è tutto. La differenza è, almeno in parte, dovuta alla presenza e all'utilizzo delle chiusure in Smalltalk, che molti altri ambienti non forniscono ancora - - in particolare C ++, C # e Java.

Answer 5

In Java viene creata una dipendenza quando si scrive qualcosa come

MyClass32 temp = this.theThing ();

Ora il tuo codice DIPENDE dalla classe MyClass32 stare in giro. Il tuo codice non funzionerà Senza esso. Qualsiasi cambiamento in quella classe può rendere il tuo codice incompatibile, richiedendo a molte altre modifiche al tuo codice, che potrebbe richiedere ulteriori cambi di codice in classe dipende dal tuo. Un sacco di lavoro extra.

In Smalltalk scriverai   temp: = self theThing;

Il tuo codice funzionerà indipendentemente da ciò che viene restituito di #getTheThing. Il tuo codice non dipende sulla classe MyClass32 in giro. Solo tu la dipendenza è che "temp" deve capire qualunque cosa messaggi che gli invii.

Quindi, in un certo senso, lo scopo dell'iniezione di dipendenza Frameworks deve creare un linguaggio tipicamente statico come Java funziona più come un dy7namically tipizzato.

Detto questo, ho spesso un DISEGNO DI DESIGN seguito in Smalltalk: crea un metodo di classe come MyClass che restituisce ALCUNA classe. Non è necessario il NOME "MyCLass". Potrebbe essere uno dei tanti lezioni, ritornando una classe diversa di notte. Questo modello è presente in Smalltalk MVC, dove le classi View hanno il metodo #defaultControllerClass, che in genere viene ridefinito da sottoclassi.