Смоллток и IoC

Question

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

Answer 1

MVC был изобретен на Smalltalk и, возможно, является оригинальным Инверсия среды управления . Хотя он несколько более легкий, чем его Java-аналоги, он имеет основные концепции модели, содержащей данные, представление, отображающее данные в ответ на события, распространяемые из контроллера.

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

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

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

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

Answer 5

В Java зависимость создается при написании что-то вроде

MyClass32 temp = this.theThing ();

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

В Smalltalk вы бы написали   temp: = self theThing;

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

Так что в некотором смысле цель внедрения зависимости Фреймворки это сделать статически типизированный язык как Java работает больше как dy7 динамически типизированный.

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