Smalltalk и IoC

Question

Я вижу много каркасов IoC для .Net и Java. Кто-нибудь знает, почему нет эквивалентных фреймворков для Smalltalk. Это скорее философский вопрос, чем что-либо другое. Мне интересно, есть ли что-то в Smalltalk для того, чтобы делать что-то, что исключает необходимость создания инфраструктуры IoC.

Answer 1

MVC был изобретен на Smalltalk и, возможно, является оригинальным каркасом Inversion of Control. В то время как несколько более легкий, чем его аналоги Java, он имеет основные концепции модели, содержащей данные, представление, представляющее данные в ответ на события, связанные с контроллером.

Менее легкомысленно, Java на самом деле нуждается в большой поддержке фреймов, чтобы делать веб-приложение без избыточного количества кода шаблона. Smalltalk поддерживает идиомы программирования, такие как continuations, которые позволяют автору притворяться, что они на самом деле не записывают код, управляемый событиями. Seaside работает так, предоставляя преимущества IoC с несколько более гибкой парадигмой развития.

EDIT: MVC - это среда для пользовательских интерфейсов в Smalltalk (возможно, это не настоящая структура как таковая, но библиотека классов имеет встроенную поддержку). Он имеет инверсию свойства управления, поскольку представление и модель реагируют на события, отправленные контроллером, - не вызывайте нас, мы будем называть вас собственностью. Inversion of Control - это шаблон проектирования в рамках фреймворков, который используется для уменьшения потребности в обширном шаблоне в приложениях Java. В некоторых определениях рамок приложения Inversion of Control является основным свойством, которое рассматривается как отличительная черта из библиотеки.

Answer 2

Функции являются гражданами первого класса в smalltalk, поэтому легко иметь IoC без рамки.

Answer 3

Я думаю, что модель ввода-вывода IOC или Injection разрешает проблему, которая на самом деле не существует в среде Smalltalk. Smalltalk - нетипизированный динамический язык и использует передачу сообщений для общения. Это создает для объектов, которые слабо связаны природой на уровне языка. Любой объект может отправлять сообщение другому объекту независимо от типа, если он может обрабатывать сообщение. Таким образом, как вы можете догадаться, изменения зависимостей в любой момент времени относительно просты и естественны. Просто нужно решить, где, когда и как вы хотите изменить зависимость.

Answer 4

Несколько возможных причин для этого. Один из них заключается в том, что мы не потрудились использовать квалификатор «IoC», который по существу является избыточным - поскольку вызов чего-то рамки подразумевает инверсию потока управления.

Другим является то, что язык Smalltalk обеспечивает прямую поддержку потоков «IoC» в виде замыканий. Одним из результатов программирования с закрытием является то, что поток управления, как он найден в рамках, не кажется настолько резко отличающимся, что вызывает чувство «перевернутого» из «нормального» смысла потока; скорее, с закрытием, поток контроля перевертывается назад и вперед между этими двумя перспективами все время и везде. Даже в отдельных заявлениях.

Третья причина, пожалуй, состоит в том, что даже без замыканий описываемая «инверсия управления» не связана однозначно с фреймворками - одни и те же потоки встречаются в большинстве форм кода, связанных с I/O.

В-четвертых, Smalltalkers, вероятно, используют эти виды потоков даже больше, чем другие, поскольку мы более склоняемся к понятиям объектов и сообщений, посланных между ними, чем к понятиям структур и вызовам функций-членов. В отсутствие закрытий эти два вида эквивалентны и взаимозаменяемы, но добавление замыканий изменяет результат - одним из эффектов является использование управляющего потока.

Наконец, можно даже подумать о том, чтобы описать стиль управления REPL как «более простой», но «перевернутый» смысл «нормального» потока, нормальный в том смысле, что он используется почти везде.

Таким образом, для Smalltalk существуют такие же структуры. Мы описываем их несколько иначе. Разница, по крайней мере частично, связана с наличием и использованием замыканий в Smalltalk, что еще не предусмотрено многими другими средами - - в особенности C++, C# и Java.

Answer 5

В Java зависимость создается, когда вы пишете что-то вроде

темп MyClass32 = this.theThing();

Теперь ваш код ЗАВИСИТ ОТ класса MyClass32 . Ваш код не будет работать без него. Любые изменения в этом классе могут сделать ваш код несовместимым, требуя дополнительных изменений в вашем коде, которые могут потребовать дополнительных изменений кода в классе , которые зависят от ваших. Много дополнительной работы.

В Smalltalk вы должны написать temp: = self theThing;

Ваш код будет работать независимо от того, что возвращается от #getTheThing. Ваш код не зависит от класса MyClass32. Ваша единственная зависимость заключается в том, что «temp» должен понимать любые сообщения , которые вы отправляете на него.

Итак, в некотором смысле цель Injection Dependency Frameworks состоит в том, чтобы сделать статически типизированный язык , как Java, больше похож на dy7namically типизированный.

Сказанное: существует КОНСТРУКЦИЯ ПРОЕКТА У меня часто Следование в Smalltalk: Создайте класс-метод, такой как MyClass, который возвращает класс SOME. Не нужно иметь ИМЯ 'MyCLass'. Это может быть один из нескольких классов , возвращающий новый класс ночью. Этот шаблон присутствует в Smalltalk MVC, , где классы View имеют метод #defaultControllerClass, , который обычно переопределяется подклассами.