Smalltalk e IoC

Question

Eu vejo um monte de quadros IoC para .NET e Java. Alguém sabe por que não há estruturas equivalentes para Smalltalk. Esta é mais uma questão filosofia do que qualquer outra coisa. Eu estou querendo saber se há algo na maneira Smalltalk de fazer as coisas que impede a necessidade de ter um quadro IoC.

Answer 1

MVC foi inventado em Smalltalk e é sem dúvida o original Inversão do quadro de controle . Embora um pouco mais leve do que suas contrapartes de java, ele tem os conceitos básicos de um modelo que contém os dados, uma vista de processar os dados em resposta a eventos propogated de um controlador.

Menos flippantly, Java é realmente precisa de muito apoio quadro para fazer uma aplicação web sem quantidades excessivas de código clichê. Smalltalk apoios idiomas, como continuações , que permitem que um autor para fingir que eles não estão realmente escrevendo evento de programação código conduzido. Mar funciona assim, dando os benefícios de IoC com um paradigma de desenvolvimento um pouco mais flexível .

EDIT: MVC é um quadro de UI em Smalltalk (sem dúvida, não é realmente um quadro como tal, mas a biblioteca de classes tem suporte embutido para ele). Ele tem a inversão de propriedade de controle em que a visão e modelo de responder a eventos despachados pelo controlador - a não nos chamam, nós vamos chamá-lo de propriedade. Inversão de Controle é um padrão de design dentro de quadros que é usado para reduzir a necessidade de extensa clichê em aplicações Java. Em algumas definições de uma estrutura de aplicativo, inversão de controle é a principal propriedade que é visto como distinguir um quadro de uma biblioteca.

Answer 2

As funções são cidadãos de primeira classe em Smalltalk, por isso é fácil ter IoC sem um quadro.

Answer 3

Eu acho que COI ou o padrão Dependency Injection resolve um problema que realmente não existe no ambiente Smalltalk. Smalltalk é uma mensagem de linguagem dinâmica e usos untyped passando de se comunicar. Isto faz para objetos que são de baixo acoplamento, por natureza, no nível da linguagem. Qualquer objeto pode enviar uma mensagem para outro objeto sem levar em conta o tipo, desde que ele pode processar a mensagem. Então, como você pode imaginar mudando dependências em um determinado momento é relativamente fácil e natural. Só tem que decidir onde, quando e como você quiser alterar a dependência.

Answer 4

Algumas razões possíveis para isso. Uma delas é que não se preocupou em usar o qualificador "JCP", que é essencialmente redundante -. Uma vez chamar algo um quadro implica a inversão do fluxo de controle

Outra é que a linguagem Smalltalk fornece suporte direto para "JCP" flui - na forma de encerramentos. Um dos resultados da programação com fechos é que o fluxo de controle como encontrado em estruturas não parece tão totalmente diferente como para evocar um sentido de ser "invertida" de um sentido "normal" de fluxo; em vez disso, com fechos, o fluxo de controle está lançando frente e para trás entre estas duas perspectivas de todos os tempos e em todos os lugares. Mesmo dentro de declarações individuais.

Uma terceira razão, talvez, é que, mesmo sem encerramentos, a "inversão de controle" que está sendo descrito não está associada exclusivamente com estruturas - os mesmos fluxos são encontrados na maioria das formas de código que envolvem E / S

Em quarto lugar, Smalltalkers provavelmente usar esses tipos de fluxos ainda mais do que outros, como nós inclinar mais fortemente sobre as noções de objetos e as mensagens enviadas entre eles do que sobre as noções de estruturas e a vocação de funções membro. Na ausência de meios de obturação, estes dois pontos de vista são equivalentes, e permutáveis, mas a adição de fechos altera o resultado -. O sentido de fluxo de controle em uso é um dos efeitos

Finalmente, pode-se até pensar em descrever o estilo REPL de fluxo de controle como um "simples", mas "invertido" sentido do "normal" fluir, normal no sentido de que ele é usado em quase todo lugar.

Em resumo, existem os mesmos tipos de estruturas para Smalltalk. Nós descrevê-los um pouco diferente é tudo. A diferença é, pelo menos em parte, devido à presença e à utilização de encerramentos em Smalltalk, que muitos outros ambientes ainda não fornecem - -. Nomeadamente C ++, C # e Java

Answer 5

Em Java uma dependência é criada quando você escreve algo como

MyClass32 temp = this.theThing ();

Agora o seu código depende da MyClass32 classe estar por perto. Seu código não vai funcionar sem ele. Qualquer mudança nessa lata classe tornar seu código uncompilable, exigindo uma muitas mudanças extras em seu código, que pode necessitar de mais de códigos mudanças na classe que dependem de seu. Lotes de trabalho extra.

Em Smalltalk você escreveria Temp: = auto theThing;

O seu código irá funcionar não importa o que é devolvido por #getTheThing. Seu código não é dependente na MyClass32 classe estar ao redor. sua única dependência é que 'temp' deve entender o que quer mensagens enviadas a ele.

Assim, em certo sentido, o propósito de Dependency Injection Frameworks é fazer com que uma linguagem de tipagem estática como o trabalho Java mais como um dy7namically digitado.

Dito isto, há um padrão de design Eu sempre seguida em Smalltalk: Crie uma classe-método como MyClass que retorna alguma classe. Ele não precisa ter O nome 'MyCLass'. Poderia ser um dos vários aulas, retornando uma classe diferente à noite. Este padrão está presente no Smalltalk MVC, onde View-classes têm o método #defaultControllerClass, que normalmente é redefinida por subclasses.