Самое начало: только объекты --- а что такое объект?

Весь Smalltalk базируется на нескольких простых принципах. Сейчас рассмотрим пару, и один --- подробно.


1. Все в Smalltalk-е является объектом.

Подробнее этот принцип обсудим в другой раз. Сейчас займемся другим пунктом... Ведь это первое утверждение, по сути, является "апофатическим": говорит о том, чего нет в Smalltalk-е --- "не-объектов". А вот что такое объект?


На самом деле, в этом вопросе содержится сразу два:

1. Что такое объект "извне" --- как ими пользоваться?
   
2. Что такое объект "изнутри" --- как он устроены и как создать "свой" объект?
   

(Объект как, соответственно, ноумен и феномен?)

Сейчас рассмотрим только первую часть.

"Извне" объект весьма прост (и в этом, наверное, и заложена вся сила ООП): объект это то, что может что-то сделать (для нас). Нужно всего лишь попросить его. Просьба --- это сообщение. В сообщении мы должны изложить суть нашей просьбы (ее "название") и указать необходимые для ее выполнения "материалы" --- другие объекты, с использованием которых просьба может быть выполнена.

Примерно так же мы пользуемся объектами в жизни (правда не всегда сообщения вербальны)?
Сообственно, мы уже "расписали" второй принцип:

2. Все вычисления выполняются через посылку сообщений.

Синтаксис Smalltalk отвечает этому принципу максимально близко к естественному языку. Для примера:

почтальон доставь: письмо по: адрес.

Примечание: Smalltalk, естественно, ориентирован на английский язык; в русской версии за счет наличия окончаний в различных падежах либо выглядит не столь "естественно" (лучше бы смотрелось "... по: адресу"), либо требует доработки компирятора (что, кстати, выглядит не очень сложной задачей). Но в любом случае далее будем использовать "нормальный" англоязычный синтаксис.

В обычном, англоязычном Smalltalk-е указанный пример будет выглядеть так:

postman deliver:  letter to: address.

Получили (почти) обычное предложение. Подлежащее в нем --- объект почтальон --- в терминах Smalltalk называется получателем (сообщения). Само сообщение включает в себя 

• "имя" (в терминах Smalltalk --- селектор; почему селектор --- будет ясно позже, при рассмотрении внутреннего устройства объектов) --- в данном случае именем является доставь:по: --- (почти) сказуемое
• аргументы (дополнения) --- объекты письмо и адрес

 

Продолжение следует...

Пример работы с mock-ами

Контекст

Сайт. Пользователь может задавать вопросы, заполняя и отправляя соответствующую форму. Вопросы представлены экземплярами класса Question. Когда вопрос изменяется (в результате редактирования пользователем) он получает сообщение #changed.

Задача

Когда изменяется вопрос, нужно отослать соответствующее оповещение администратору сайта.

Решение

(1) QuestionTests >> testNotifiesAdminOnChange
(2)  | question |
(3)  question := Question new.
(4)  [ :notifier |
(5)    question notifier: notifier.
(6)    [ question changed ] 
(7)        should strictly satisfy:
(8)            [ notifier notifyAdminAbout: question ] 
(9)  ] runScenario

Пояснение

В строках (4) -- (9) создается сценарий.
Параметры сценария (строка (4)) инициализируются mock-объектами.
В блоке (6) описываются действия, определяющие тестируемую ситуацию: question получает сообщение #changed.
В строке (7) задается условие: в результате этих (заданных выше в строке (6) действий должно происходить строго в заданной последовательности то, что записано в блоке строки (8).
В этом блоке записано, что объект notifier должен получить сообщение #notifyAdminAbout: с аргументом, идентичным question.

Обратите внимание! Не указывается, к какому классу будут принадлежать нотификаторы, с которыми будут работать вопросы.
Далее разработка будет включать шаги по созданию и описанию поведения такого класса.

Замечание

Также, возможно, потребуется рефакторинг по вынесению адресата оповещения в параметр и (в дальнейшем, возможно) изменению системы отсылки сообщения. На это указывает наличие указания на адресата (admin) в селекторе сообщения #notifyAdminAbout:.

Идея и некоторые тезисы курса по ГМ и Smalltalk

Логика примерно такая:

Гибкие методологии --- это хорошо. Поэтому их надо применять. Применять можно на разных уровнях. Базовый уровень --- программистский. Здесь работает Test-Driven Development.

Чтобы эффективно применять TDD, нужны соответствующие средства. Mainstream-овые языки на эту роль подходят не очень хорошо. С динамическими скриптовыми языками (которые тоже потихонечьку смываются в главный поток) дела, наверное, получше, но и у них многовато недостатков. В применении к ГМ на сегодняшний день Smalltalk --- (как минимум) одно из лучших решений. Поэтому будем его изучать.

Эти мысли излагаются на первых двух--трех лекциях. Далее "вперемжку" (!) небольшими кусками излагаются основы программирования на Smalltalk и Test-Driven Development.

Примечание 1. Про гибкие методологии

Гибкие методологии --- не очень адекватный перевод терамина Agile methodology.

Agile --- проворный, шустрый, сообразительный.
Под гибкостью же у нас издревле понимают некую универсальность, возможность приспособить (уже готовое) программную систему под любые нужды и сделать это без программирования, "играясь настройками". То есть, "гибкое" в данном понимании --- синоним сложного с целью универсальности.

Идея agile --- практически обратная: простота, достаточная для конкретного узкого применения. Но простота "правильная", позволяющая приспособить код к новым задачам. Делать это предполагается программно и без серьезного усложнения кода --- по крайней мере, без претензий на то, что наш код будет без изменений работать для любых задач. Другими словами, в основе agile лежит осознание того факта, что написать универсальный код неимоверно (или по крайней мере, слишком) сложно, и мы лучше напишем просто работающий код, но будем готовы его изменять под новые задачи.

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

Примечание 2. Про скриптовые динамические языки программирования

Тезис по поводу скриптовых языков требует проработки и обоснования. Однако отсутствие единой среды разработки и выполнения --- уже весьма существенный "минус" (по крайней мере для разработки более-менее крупных систем).

Примечание 3. Почему Smalltalk?

Собственно, цель курса и состоит в том, чтобы ответ на этот вопрос был бы понят и прочувствован.

В кратком виде аргументация такова: Smalltalk очень прост в своей основе но при этом его выразительные возможности огромны.
(Изначально хотел написать много тезисов. Но, похоже, все они лишь комментируют и обосновывают данный. С ними будем разбираться уже в лекциях непосредственно по Smalltalk.)