Veo muchos frameworks 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 forma de hacer Smalltalk que excluya la necesidad de tener un framework de IoC.Smalltalk y IoC
MVC fue inventado en Smalltalk y es posiblemente el marco original Inversion of Control. Aunque es un poco más liviano que sus contrapartes de Java, tiene los conceptos básicos de un modelo que contiene los datos, una vista que representa los datos en respuesta a los eventos propuestos desde un controlador.
Menos vacilante, 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 de programación como continuations, que permiten a un autor fingir que no está realmente escribiendo el código de evento. Seaside funciona de esta manera, dando a los beneficios de la IoC un paradigma de desarrollo algo más flexible.
EDIT: MVC es un framework para UI en Smalltalk (posiblemente no es realmente un framework como tal, pero la biblioteca de clases lo ha incorporado). 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 llame, le llamaremos propiedad. Inversion of Control es un patrón de diseño dentro de frameworks que se usa para reducir la necesidad de un extenso modelo en aplicaciones java. En algunas definiciones de un marco de aplicación, Inversión de control es la propiedad principal que se considera que distingue un marco de una biblioteca.
Nigel: sabía que MVC se originó con Smalltalk. Lo que me confunde acerca de esto es que el framework IoC como Castle contiene un framework MVC (MonoRail) y un framework IoC (Windsor) que sugiere que son diferentes. – mchean
Problema de idioma: Delegates/Closures/Callbacks/EventHandling es tan fácil en una plataforma smalltalk, que no se debe marcar. Porque es más difícil lograr IoC en otras plataformas, y porque requiere un código de andamiaje (framework) para implementarse bien, y consistentemente, uno podría esperar ver un requerimiento para dicho código de andamio en Smalltalk. No hay tal necesidad. Porque es fácil. –
Las funciones son ciudadanos de primera clase en smalltalk, por lo que es fácil tener IoC sin un marco.
Creo que el IOC o el patrón Dependency Injection resuelven un problema que realmente no existe en el entorno de Smalltalk. Smalltalk es un lenguaje dinámico sin tipo y usa el mensaje que pasa para comunicarse. Esto hace que los objetos que están vagamente unidos por la naturaleza en el nivel de lenguaje. Cualquier objeto puede enviar un mensaje a otro objeto sin importar el tipo, siempre que pueda procesar el mensaje. Por lo tanto, como podría 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.
"resuelve un problema que realmente no existe en Smalltalk" - * yes * Además, los programadores de Smalltalk son más amables con los gatitos: http://www.flickr.com/photos/dafydd_ll_rees/4528702680/ – daf
Algunas posibles razones para esto. Una es que no nos hemos molestado en utilizar el calificador "IoC", 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 flujos "IoC" - en forma de cierres. Uno de los resultados de la programación con cierres es que el flujo de control que se encuentra en los marcos no parece tan diferente como para evocar una sensación de "inversión" de un sentido de flujo "normal"; más bien, con cierres, el flujo de control oscila 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" que se describe no está asociada exclusivamente a marcos; los mismos flujos se encuentran en la mayoría de las formas de código que involucran E/S.
En cuarto lugar, los Smalltalkers probablemente utilizan 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 llamadas de funciones miembro. En ausencia de cierres, estos dos puntos de vista 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 de flujo de control como un sentido "más simple", pero "invertido" del flujo "normal", 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 se debe, al menos en parte, a la presencia y utilización de de cierres en Smalltalk, que muchos otros entornos aún no proporcionan: , especialmente C++, C# y Java.
En Java una dependencia que se crea cuando se escribe algo así como
temp = MyClass32 this.theThing();
Ahora su código DEPENDE de la clase MyClass32 estando cerca. Su código no funcionará sin él. Cualquier cambio en esa clase puede hacer que su código no sea posible, requiriendo muchos cambios adicionales en su código, que puede requerir más cambios de código en la clase que dependan de la suya. Mucho trabajo extra
En Smalltalk escribiría temp: = self theThing;
Su código funcionará sin importar lo que se devuelva por #getTheThing. Su código no es dependiente de en la clase en que está MyClass32. Su única dependencia es que 'temp' debe comprender los mensajes que le envíe.
Así que en cierto sentido, el propósito de la inyección de dependencias Marcos es hacer un lenguaje de tipos estáticos como Java funciona más como un dy7namically mecanografiadas uno.
Dicho esto, hay un PATRÓN DE DISEÑO He seguido seguido en Smalltalk: Crear un método de clase como MyClass que devuelve ALGUNA clase. No necesita tener el NOMBRE 'MyCLass'. Podría ser una de varias clases de , y devolver una clase diferente por la noche. Este patrón está presente en Smalltalk MVC, , donde View-classes tiene el método #defaultControllerClass, , que normalmente se redefine por subclases.
¡Gran pregunta! – daf