Бертран Мейер - Основы объектно-ориентированного программирования

Для реализации fresh и recycle , можно среди других возможных вариантов представить available как стек: fresh будет удалять элемент из стека, а recycle будет помещать элемент в стек. Создадим класс STACK_OF_LINKABLES для этого случая и добавим следующие закрытые компоненты в класс LINKED_LIST (В упражнении У23.1. требуется определить, будет ли корректным появление у функции fresh побочных эффектов.):

available: STACK_OF_LINKABLES

fresh (v: ELEMENT_TYPE): LINKABLE is

- Новый элемент со значением v, для повторного

- использования во вставке

do

if available.empty then

- Создание нового элемента

create Result.make (v)

else

- Повторное использование linkable

Result := available.item; Result.put (v); available.remove

end

end

recycle (dead: LINKABLE) is

-Возвращает dead в список достижимых элементов.

require

dead /= Void

do

available.put (dead)

end

Мы можем объявить класс STACK_OF_LINKABLES следующим образом:

class

STACK_OF_LINKABLES

feature {LINKED_LIST}

item: LINKABLE

- Элемент в вершине стека

empty: BOOLEAN is

- нет элементов в стеке?

do

Result := (item = Void)

end

put (element: LINKABLE) is

- Добавить элемент в вершину стека.

require

element /= Void

do

element.put_right (item); item := element

end

remove is

- Удалить последний добавленный элемент.

require

not empty

do

item := item.right

end

end

Рис. 9.13. STACK_OF_LINKABLES

Представление стека использует все преимущества поля right , присутствующего в каждом элементе LINKABLE , связывая все утилизированные элементы и предоставляя, тем самым, дополнительную память для размещения новых элементов списка LINKED_LIST . Класс LINKABLE должен экспортировать свои компоненты right и put_right в класс STACK_OF_LINKABLES.

Компонент available является атрибутом класса. Это означает, что каждый связный список будет иметь свой собственный стек. Конечно, память можно было бы использовать эффективнее в системе, содержащей несколько списков и единственный стек для всех удаленных элементов. Такая техника однократных функций ( once functions ), будет представлена позже; применение ее для available означает, что только один экземпляр класса STACK_OF_LINKABLES будет существовать до конца выполнения системы, что означает достижение поставленной цели. ( Упражнение У9.3. и У9.4. Об однократных функциях см. лекцию 18)

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

Недостатки и польза - понятны. Проблемы ручного управления памятью (угроза ненадежности, монотонность) не исчезают магически. Защищенная от неправильного использования схема управления памятью, например, для связного списка, - трудна. Но вместо того, чтобы бороться с проблемой каждому разработчику приложений, работа возлагается на производителя компонентов. Чрезмерные усилия, затрачиваемые производителями компонент, окупаются тем, что созданные компоненты многократно используются различными приложениями.

Ни один из рассмотренных подходов не является полностью удовлетворительным. Общее решение проблемы управления памятью предполагает серьезную работу на уровне реализации языка.

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

Предыдущее обсуждение достаточно ясно показало, как важно иметь возможность управлять памятью. По словам Михаила Швейцера (Michael Schweitzer) и Ламберта Стретра (Lambert Strether): "ОО-программа без автоматического управления памятью то же самое, что скороварка без клапана безопасности: рано или поздно она взорвется!" (Из [Schweitzer 1991])

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

При выборе ОО-среды - или просто компилятора ОО-языка - для разработки программного продукта ограничьте ваше внимание только теми решениями, которые предлагают автоматическое управление памятью.

Два главных подхода применимы при автоматическом управлении памятью: подсчет ссылок и сборка мусора. Они оба достойны внимания, хотя второй намного мощнее и обще применим.

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

[x].Механизм может добавить память, занимаемую объектом, к постоянно поддерживаемому "списку свободных ячеек", в духе техники, использованной при рассмотрении подхода на уровне компонентов. Последующая инструкция создания ( create x... ) вначале обратится к этому списку для выделения памяти новому объекту. Только если этот список пуст или нет подходящих ячеек, инструкция запросит память у операционной системы. Этот подход может быть назван внутренний список свободной памяти.

[x].Альтернативой является возвращение занимаемой объектом памяти операционной системе. На практике это решение включает в себя некоторые аспекты первого: для избежания переизбытка системных вызовов, утилизированные объекты могут временно храниться в списке, возвращаемого операционной системе при достижении определенного предела. Этот подход может быть назван реальным восстановлением.