Great Leap Forward from Java to Smalltalk
Автор Chris Uppal
Перевод Андрея Собчука, 2003
> Я купил "Smalltalk Companion" Теда Брэчта (Ted Bracht), что бы определиться
> смогу ли я быстро обучиться Smalltalk-у. Я несколько лет программировал на
> Java, и, мне кажется, хорошо понимаю суть ООП.
> [...]
> Однако я понимаю, что я стараюсь перенести концепции, которые
> изучил в процессе разработки на Java, как на языке, основаном на файлах,
> с его итеративным процессом разработки редактировать/скомпилировать/протестировать
> на основанный на образе объектной памяти (image-based) интерактивный
> процесс разработки Smalltalk.
Добро пожаловать на борт!
Несколько лет назад я совершил Большой Скачок Вперёд с Java на (Dolphin) Smalltalk, и, я думаю, я всё еще помню свои ощущения при этом. Мои мотивы не очень отличались от ваших -- преобладал интерес узнать больше о том, о чем говорят, как о более продуктивном способе разработки. Но я узнал не совсем то, чего ожидал. Я надеялся найти более лучший инструментарий, а нашел другой взгляд на ОО.
У вас уже есть пара достаточно точных ответов на ваши отдельные вопросы. Я же хочу сделать шаг назад и немного поговорить о новом способе мышления. Я попытаюсь соотнести это с вашими вопросами, но связь может оказаться довольно косвенной.
Кстати, всё это, совершенно очевидно, только моё мнение. Другие Smalltalk-еры могут не соглашаться с большинством, если не со всеми, моими мыслями.
"Образ" - это центральное понятие в Smalltalk-е. В сравнении с ним ничто другое не является настолько важным. (Я знаю, что существуют диалекты, у которых нет образа, но лично я не вижу в этом смысла). Если мы с вами похожи, тогда вы сейчас думаете, что главным различием между Java и Smalltalk-ом является то, что в Java код хранится в файлах, а в Smalltalk-е в образе. Это часть правды, и я еще вернусь к этому вопросу, но на минуту забудьте о коде, это, в действительности, не самый важный момент. Что важно, так это объекты.
Образ - это место, где обитают объекты. Технически, образ это куча со сборщиком мусора, которую можно сохранить в файл, а позже восстановить, сохраняя и восстанавливая, таким способом, состояние вычислений. Технически -- это так и есть, но думать так -- абсолютно бесполезно. Более органическая метафора является намного лучшей. Я думаю об образе, как о глубоком, тёмном море, где живые объекты передвигаются в глубинах подобно рыбам. Даже если я спроектировал и написал классы, с момента создания все объекты начинают независимое от меня существование. Я могу общаться с ними, я могу попросить их выполнить какое-то действие, но они отделены от меня. Это "мои" объекты, но они "мои" в том смысле как и домашние животные, или куст розы, или стол.
В образе живут объекты. Не код, а объекты. Мы вернёмся к коду по ходу, но не сейчас. Среда Smalltalk это место в котором вы можете общаться с объектами, не больше и не меньше. О, естественно там есть Просмотрщик классов, отладчик, редактор, и т.п., но это всё мишура. Важно лишь то, что это место где вы можете взаимодействовать с объектами.
К "мишуре" я вернусь тоже несколько попозже, а сейчас, я хотел бы поговорить об одном элементе среды, целью существования которого является не просто продуктивность - Рабочая область (Workspace). Рабочая область - это средство с помощью которого вы общаетесь с объектами. Вы можете описать рабочую область, как "содержащая куски кода", который вы исполняете, но, по-моему, это абсолютно неверно. Это гораздо лучше звучит (слегка иронично) как бар для одиноких, где вы можете встретить объекты, поговорить с ними, пригласить их, познакомиться поближе. У каждой рабочей области есть некоторые объекты, которые (временно) живут в ней; это значения переменных области. Часто они умирают, как только вы закроете рабочую область, а до тех пор они живут и с ними можно общаться. Некоторые области я держу открытыми по несколько дней, если в них есть объекты, которые важны для моей работы. "Разговариваете" вы с объектом, посылая ему сообщения на языке Smalltalk, но это мелочи. Важно то, что вы взаимодействуете с объектами через интерактивную тексто-ориентированную среду, наподобие канала IRC.
Мне очень нравится такая аналогия. Рабочая область сродни каналу IRC для разговора с объектами. Единственное различие -- это то, что другие пользователи настоящего канала обычно не умирают, когда вы покидаете канал (по крайней мере, мне так кажется, хотя я никогда не использовал IRC).
(Кстати, вы можете сохранить текст из Рабочей области в .ST файл -- в действительности текст сохраняется как RTF -- но это аналог сохранения транскрипта разговора. Если вы откроете текст в другой рабочей области, то вы будете видеть текст, но объектов не будет. Использование cut-and-paste из одной рабочей области в другую даёт тот же эффект и является хорошим способом избавления от ненужных объектов без потери того, что же было сказано).
Другой способ взаимодействия с объектами -- это Инспектор. Он даёт намного более детальный, низкоуровневый вид на объекты. Более интимный вид, если вам так больше нравится. Лично я не думаю, что мир Smalltalk-а уже дошел до того, чем инспектор может быть, но текущая реализация (такая как "flipper" в Dolphin), как минимум, позволяет видеть внутренности объекта.
Образ содержит множество объектов, некоторые долгоживущие (они живут, возможно, десятилетиями), хотя большинство живёт недолго. Некоторые объекты очень простые, например, Строки (Strings) и Точки (Points). У других более сложная внутреннея структура и/или более сложное поведение. Но все они являются объектами, живут в образе, и вы общаетесь с ними в рабочих областях.
Одними из интерестных видов объектов являются классы. Помните, что я все ещё не говорю о коде (позже), я говорю об объектах, которые называются классы. Как и любой другой объект, вы можете пригласить их поговорить в рабочей области:
class := String
и затем можно использовать волшебный Smalltalk-овый объектно-ориентированный IRC для разговора с классом:
class name. "--> #String" class allSubclasses size. "--> 3"
и так далее. Таким образом, все классы являются объектами, и живут в образе.
Так как Smalltalk это среда программирования с графикой, то естесвенным желанием будет, получив образ, заполненный объектами, начать писать инструментарий, который позволит взаимодействовать с объектами более структурированым/удобным способом. Рабочие области и Инспектора очень хороши для базовых вещей, но мы вскоре захотим лучшего инструментария, который позволит видеть связи между объектами (или некоторым подможеством объектов, классами, например), или сообщения, которые они понимают. Возможно мы захотим изменять их поведение, или создавать новые виды объектов. Это именно то, что позволяет делать IDE. Просмотрщик классов и прочее, это всего лишь набор инструментов для общения с объектами. Они полезные, даже очень желательные, но, в конце концов, необязательные, так как мы можем общаться с объектами и без них.
А сейчас пора вернуться к разговору о коде. Выбранное мною направление, начиная с объектов, затем важные инструменты, затем классы, еще об инструментах, и, наконец, код, представляет собой движение от более важных аспектов к менее важным. С такой точки зрения код -- это наименее важная часть программирования в Smalltalk-е. (Естественно, я через чур преувеличиваю. Я действительно не думаю, что код наименее важен из всех частей -- только попробуйте испортить форматирование моего кода, увидите как я взорвусь -- с другой стороны, я действительно думаю, что объекты более важны).
Код -- это средство сказать объектам, как они должны себя вести. Это текст на языке программирования Smalltalk. Мы программисты, а значит мы должны работать и с кодом; когда мы писали инструментарий, способный отображать внутреннее устройство объектов, мы, естественно, заложили туда возможность просмотра связанного с объектом исходного кода. Например, наш специальный инструмент для просмотра классов (Просмотрщик иерархии классов) позволяет нам видеть исходный код методов, изменять его, перекомпилировать и т.д. Это естественно для нас, как программистов. Если бы мы были не программистами, то мы бы захотели и другие инструменты, заинтересовались бы в общении с другими объектами. Подобные системы, созданные для непрограммистов, называются "приложения", но и они всего-навсего Smalltalk-инструменты для общения с объектами, живущими в образе. (Основное различие в том, что "образ" приложения обычно не сохраняемый, в отличие от образа IDE).
Вернёмся к коду. Принимая, что самыми важными являются объекты и то, как они себя ведут. Нам всё еще нужно думать о коде. Мы хотим упорядочить его, сделать резервные копии, положить в систему контроля версий, и т.п. Класс -- это объект, который живёт в образе, но исходный код для этого класса -- это нечто другое. Из-за всех вышеперечисленных причин, мы хотим хранить код вне образа. В Dolphin исходный код упорядочивается при помощи Пакетов (Packages). Пакет состоит из исходного кода классов и методов (там есть еще пара вещей, не важных сейчас), которые хранятся вне образа в одном или более файлов. Вы можете загрузить пакет в образ. В этот момент будут созданы объект Пакет и Классы, соответсвующие исходному коду. Или вы можете "деинсталировать" пакет, что приведёт к уничтожению объекта Пакета и всех Классов.
Таким образом, пакеты -- это способ объеденить части исходного кода, которые относятся друг к другу. Некоторые Smalltalk-системы идут дальше, и связывают с пакетами пространства имён. Dolphin так не делает (и я не думаю, что это плохо). Вы можете загрузить один и тот же пакет в разные образы, в этом случае у вас будут дубликаты версий объектов классов, живущие в обоих образах. Если вы так поступите, то вам нужно быть осторожным, чтобы не изменить классы только в одном из образов, так как файл пакета не может отражать состояние обоих образов одновременно. Устройство пакетов относительно простое; его можно усовершенствовать, но оно вполне удовлетворяет мои нужды. Файлы пакетов -- это текстовые файлы, вы можете редактировать их в vi или notepad, или в любом другом редакторе. Иногда я так поступаю, когда хочу внести косметические изменения в исходники. Естесвенно, если вы так поступите, то будете должны установить изменённую версию пакета в образ, перед тем как использовать его.
Обратите внимание, насколько такой способ мышления отличается от того к которому принуждают даже лучшие Java IDE. Когда я начал работать с Smalltalk-ом, то думал о Smalltalk IDE, как о Java IDE. Я думал о ней, как об инструменте, который позволяет мне писать код, и имеет инструменты, которые позволяют мне смотреть и тестировать код. Год спустя я понял, что перевернул всё с головы на ноги, и, соответсвенно, изменилось моё понимание концепции объектно- ориентированного программирования в целом. Как программист на Java (или C++), я думал, что мои .java (и .cpp) файлы это классы, а программирование -- это создание классов. Теперь я думаю, что самое важное -- это объекты, а классы вторичны, и не более чем особенности реализации.
Я чувствую, что в результате я стал более хорошим программистом. Разумеется, нельзя быть абсолютно уверенным, но если это так, то всё это благодаря Рабочим областям (Workspaces) Smalltalk-а.
(Пара заметок для опытных программистов на Smalltalk-е, если кто-нибудь из
них еще читает:
Был ли Dolphin первым Smalltalk-ом у которого рабочие области запоминали,
а не отбрасывали значения переменных после каждого вычисления? VW раньше
отбрасывал их, и, по-моему, VAST всё еще так и поступает. Squeak сохраняет
значения, но я не знаю как давно он имеет такое поведение. В любом случае,
какая бы реализация Smalltalk-а не ввела подобную возможность, по-моему,
она может считаться первым действительно объектно-ориентированным
Smalltalk-ом. По-видимому, это так же первая действительно
объектно-ориентированная IDE. Пока я писал эти строчки, я сосредоточился на
ощущении беспокойства, которое я всё еще испытываю, программируя в отладчике.
Я подозревал, что это может привести к (запутанному) подходу сверху-вниз
к декомпозиции. Сейчас мне интересно, является ли это также частью
"ориентированного на код", а не "объектно ориентированного" способа думать,
к которому должен приводить Smalltalk).
Кстати, я очень рекомендую по Smalltalk-у книгу (особенно если вас не устраивает подход Тэда Брэчта (Ted Branht) "обучение на примерах") Чемонда Лью (Chammond Liu) "Smalltalk Objects, and Design". Это лучшая из всех книг по Smalltalk-у, которые я читал (так же она не специфическая для Dolphin-а), и, я уверен, это лучшая книга и по ОО.
Ну и. Опять же, пост получился длиннее, чем я ожидал. Я не знаю, всё ли из того, что я сказал вам будет интересно, или даже покажется ли относящимся к делу. Тем не менее, я получил удовольствие от написания письма...
Chris Uppal