Smalltalk и IoC

Question

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

MyClass32 temp = this.theThing ();

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

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

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

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

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

Answer 5

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

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

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

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

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

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