Программирование на языке Ruby
вернуться

Фултон Хэл
Шрифт:

Имейте в виду, что в Ruby применяется консервативный вариант сборки мусора по алгоритму пометки и удаления. Нет гарантии, что любой объект будет убран до завершения программы.

Однако все это может оказаться и ненужным. В Ruby существует стиль программирования, в котором для инкапсуляции работы с ресурсами служат блоки. В конце блока ресурс освобождается, и жизнь продолжается без помощи чистильщиков. Рассмотрим, например, блочную форму метода

File.open
:

File.open("myfile.txt") do |file|

 line1 = file.read

 # ...

end

Здесь в блок передается объект

File
, а по выходе из блока файл закрывается, причем все это делается под контролем метода
open
. Функциональное подмножество метода
File.open
на чистом Ruby (сейчас этот метод ради эффективности написан на С) могло бы выглядеть так:

def File.open(name, mode = "r")

 f = os_file_open(name, mode)

 if block_given?

begin

yield f

ensure

f.close

end

return nil

 else

return f

 end

end

Мы проверяем наличие блока. Если блок был передан, то мы вызываем его, передавая открытый файл. Делается это в контексте блока

begin-end
, который гарантирует, что файл будет закрыт по выходе из блока, даже если произойдет исключение.

11.4. Заключение

В этой главе были приведены примеры использования более сложных и даже экзотических механизмов ООП, а также решения некоторых рутинных задач. Мы видели, как реализуются некоторые паттерны проектирования. Познакомились мы и с API отражения в Ruby, продемонстрировали ряд интересных следствий динамической природы Ruby и некоторые трюки, возможные в динамическом языке.

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

В современном окружении таким приложениям часто необходим графический интерфейс. В главе 12 мы рассмотрим создание графических интерфейсов на языке Ruby.

Глава 12. Графические интерфейсы для Ruby

Нет ничего хуже четкого образа нечеткой идеи.

Апсель Адамс

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

Я не думаю, что командная строка не переживет следующее десятилетие — у нее есть свое место в мире. Но даже закоренелые хакеры прежних лет (предпочитающие команду

cp -R
перетаскиванию файлов мышкой) все-таки не прочь воспользоваться ГИ, когда это оправданно.

Однако у графического программирования есть свои сложности. Главная проблема, конечно, состоит в том, чтобы определить, как должен выглядеть удобный интерфейс к программе; при проектировании интерфейсов картинка не всегда заменяет тысячу слов. В этой книге мы не можем уделить внимание данному аспекту, все-таки наша тема — не эргономика, не эстетика и не психология.

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

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

Эта глава не поможет вам в разрешении вышеназванных проблем. Максимум, что я могу сделать, — предложить очень краткое введение в несколько популярных графических систем (в той мере, в какой они относятся к Ruby), а также несколько советов и наблюдений.

Большая часть главы посвящена библиотекам Tk, GTK+, FOX и Qt. Велики шансы на то, что у вас возникнет вопрос: «А почему здесь нет (подставьте имя своей любимой библиотеки)?»

Причин несколько. Прежде всего это ограниченность места: все же книга посвящена не только графическим интерфейсам. Другая причина заключается в том, что для вашей системы могут быть еще не написаны привязки к Ruby (и в таком случае мы призываем вас этим заняться). И наконец, не все графические интерфейсы «равны». Мы попытались рассказать о самых важных и зрелых, а остальные только упомянули.