Smalltalk y IoC

Question

Veo muchos marcos IoC para .Net y Java. ¿Alguien sabe por qué no hay marcos equivalentes para Smalltalk? Esta es más una cuestión de filosofía que cualquier otra cosa. Me pregunto si hay algo en la manera de Smalltalk de hacer las cosas que excluya la necesidad de tener un marco de IoC.

Answer 1

MVC se inventó en Smalltalk y es posiblemente el original Inversión de control . Aunque es algo más ligero que sus homólogos de Java, tiene los conceptos básicos de un modelo que contiene los datos, una vista que muestra los datos en respuesta a los eventos propagados desde un controlador.

De manera menos efusiva, Java en realidad necesita una gran cantidad de soporte de framework para hacer una aplicación web sin cantidades excesivas de código repetitivo. Smalltalk admite expresiones idiomáticas de programación tales como continuations , que permiten a un autor pretender que no está realmente escribiendo un evento código impulsado Seaside funciona así, brindando los beneficios de IoC con un paradigma de desarrollo algo más flexible .

EDIT: MVC es un marco para IU en Smalltalk (podría decirse que no es realmente un marco como tal, pero la biblioteca de clases tiene soporte incorporado para él). Tiene la propiedad de inversión de control en el sentido de que la vista y el modelo responden a los eventos enviados por el controlador: no nos llamen, lo llamaremos propiedad. Inversion of Control es un patrón de diseño dentro de marcos que se usa para reducir la necesidad de una amplia plantilla en aplicaciones Java. En algunas definiciones de un marco de aplicación, Inversion of Control es la propiedad principal que se considera que distingue un marco de una biblioteca.

Answer 2

Las funciones son ciudadanos de primera clase en smalltalk, por lo que es fácil tener IoC sin un marco.

Answer 3

Creo que IOC o el patrón de inyección de dependencia resuelve un problema que realmente no existe en el entorno Smalltalk. Smalltalk es un lenguaje dinámico sin tipo y utiliza el paso de mensajes para comunicarse. Esto se traduce en objetos que se acoplan de forma flexible en el nivel del lenguaje. Cualquier objeto puede enviar un mensaje a otro objeto sin importar el tipo, siempre y cuando pueda procesar el mensaje. Entonces, como puede suponer, cambiar las dependencias en un momento dado es relativamente fácil y natural. Solo tiene que decidir dónde, cuándo y cómo desea cambiar la dependencia.

Answer 4

Algunas posibles razones para esto. Una es que no nos hemos molestado en utilizar el " IoC " calificador, que es esencialmente redundante, ya que llamar a algo un marco implica la inversión del flujo de control.

Otra es que el lenguaje Smalltalk proporciona soporte directo para " IoC " Flujos - en forma de cierres. Un resultado de la programación con cierres es que el flujo de control que se encuentra en los marcos no parece ser tan diferente como para evocar una sensación de estar "invertido" de un " normal " sentido de flujo más bien, con los cierres, el flujo de control se mueve de un lado a otro entre estas dos perspectivas todo el tiempo y en todas partes. Incluso dentro de declaraciones individuales.

Una tercera razón, tal vez, es que, incluso sin cierres, la inversión de control " la descripción no se asocia de forma única con los marcos, los mismos flujos se encuentran en la mayoría de las formas de código que implican I / O.

Cuarto, los Smalltalkers probablemente usan este tipo de flujos incluso más que otros, ya que nos apoyamos más en las nociones de objetos y los mensajes enviados entre ellos que en las nociones de estructuras y la llamada de funciones miembro. En ausencia de cierres, estas dos vistas son equivalentes e intercambiables, pero la adición de cierres cambia el resultado: la sensación de flujo de control en uso es uno de los efectos.

Finalmente, uno podría incluso pensar en describir el estilo REPL del flujo de control como "más simple", pero "invertido" sentido de la " normal " Flujo, normal en el sentido de que se usa en casi cualquier otro lugar.

En resumen, existen los mismos tipos de marcos para Smalltalk. Los describimos un poco diferente es todo. La diferencia es, al menos en parte, debido a la presencia y utilización. de cierres en Smalltalk, que muchos otros entornos aún no proporcionan - - notablemente C ++, C # y Java.

Answer 5

En Java se crea una dependencia cuando escribes algo como

MyClass32 temp = this.theThing ();

Ahora su código DEPENDE en la clase MyClass32 estar cerca de. Tu código no funcionará sin ello. Cualquier cambio en esa clase puede haga su código no compilable, requiriendo un muchos cambios adicionales en tu código, que puede requerir más cambios de código en la clase Eso depende de lo tuyo. Mucho trabajo extra.

En Smalltalk escribirías   temp: = auto theThing;

Tu código funcionará sin importar lo que se devuelva por #getTheThing. Tu código no es dependiente en la clase MyClass32 estar alrededor. Tu único la dependencia es que 'temp' debe entender lo que sea mensajes que le envíes.

Entonces, en cierto sentido, el propósito de la inyección de dependencia Frameworks es hacer un lenguaje mecanografiado estáticamente. al igual que Java, funciona más como un tipo dinámicamente escrito.

Dicho esto, hay un PATRÓN DE DISEÑO que a menudo seguido en Smalltalk: Crear un método de clase como MyClass que devuelve SOME class. No necesita tener el NOMBRE 'MyCLass'. Podría ser uno de varios Clases, regresando una clase diferente por la noche. Este patrón está presente en el Smalltalk MVC, donde las clases de vista tienen el método #defaultControllerClass, que es típicamente redefinido por subclases.