Книга: Основы объектно-ориентированного программирования

Удаление объектов, управляемое программистом

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

Это простейшее решение для реализаторов языка: все, что от них требуется, - это ввести в язык примитив, скажем, reclaim, такой что a.reclaim сообщает системе, что объект, присоединенный к a, не нужен, и соответствующие ячейки памяти можно освободить для новых объектов.

Это решение реализовано в не ОО-языках, таких как Pascal (dispose процедура), C (free), PL/I (FREE), Modula-2 и Ada. Оно есть в большинстве 'гибридных ОО" языков, в частности в C++.

Такое решение особенно приветствуется в мире С-программистов, любящих полностью контролировать происходящее. Обычная реакция таких программистов на тезис о том, что Objective-C может давать преимущества, благодаря автоматическому восстановлению памяти, следующая:

Для серьезной разработки программ эта позиция не позволительна. Хорошие разработчики должны разрешать кому-либо другому играть со своими "игрушками" по двум причинам: надежности и простоты разработки.

Проблема надежности

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

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

Этот тип ошибки известен, как источник появления самых частых и неприятных жучков в практике языка С и производных языков. Программисты боятся таких жучков из-за трудности обнаружения их источника. Если программист не заметил, что определенная ссылка еще присоединена к объекту и как результат - ошибочно выполняет reclaim, то это часто происходит из-за того, что ссылка находится в другой части программы. Если так, то должна быть большая физическая и концептуальная дистанция между ошибкой - вызовом reclaim и ее проявлением - крах или другое ненормальное поведение из-за попытки применения некорректной ссылки. Проявиться ошибка может значительно позже и, по-видимому, совсем в другой части программы. К тому же, ошибка может быть плохо воспроизводимой, поскольку распределение памяти операционной системой не всегда происходит одинаково и может зависеть от внешних по отношению к программе факторов.

Сказать, что причиной этих ошибок является "плохой стиль программирования", как в письме, упомянутом выше, это не сказать ничего. Человеку свойственно ошибаться; ошибки при программировании неизбежны. Даже в приложениях средней сложности, нет разработчиков, которым можно доверять, нельзя доверять самому себе в способности проследить за всеми объектами периода выполнения. Это работа не для человека, с ней может справиться только компьютер.

Многие из С или С++ программистов ночи проводят, пытаясь понять, что произошло с одной из их игрушек. Нередко, что проект задерживается из-за загадочных ошибок при работе с памятью.

Проблема простоты разработки

Даже если можно было бы избежать ошибочных вызовов reclaim, остается вопрос - сколь реально просить разработчиков управлять удалением объектов? Загвоздка в том, что даже при обнаружении объекта, подлежащего утилизации, обычно просто удалить его недостаточно, он может сам содержать ссылки на другие объекты и нужно решить, что с ними делать.

Рассмотрим структуру, показанную на рис.9.10, ту же, что использовалась в предыдущей лекции для описания динамической природы объектных структур. Допустим, выяснилось, что можно утилизировать самый верхний объект. Тогда в отсутствии каких-либо других ссылок можно удалить и другие два объекта, на один из которых он ссылается прямо, а на другой - косвенно. Не только можно, но и нужно: разве хорошо удалять только часть структуры? В терминологии Pascal это иногда называется рекурсивной проблемой удаления: если операции утилизации имеют смысл, они должны быть рекурсивно применены ко всей структуре данных, а не только к одному индивидуальному объекту. Но конечно, необходимо быть уверенным, что на объекты удаляемой структуры нет ссылок из внешних объектов. Это трудная и чреватая ошибками задача.

Рис. 9.10.  Прямые и косвенные взаимные ссылки

На этом рисунке все объекты одного типа PERSON1. Предположим, что сущность x присоединена к объекту О типа MY_TYPE , объявленным как класс:

class MY_TYPE feature
attr1: TYPE_1
attr2: TYPE_2
end

Каждый объект типа MY_TYPE, такой как О, содержит две ссылки, которые (кроме void) присоединены к объектам типа TYPE_1 и TYPE_2. Утилизация О может предполагать, что эти два объекта тоже должны быть утилизированы, также как и зависимые от них объекты. Выполнение рекурсивной утилизации, в этом случае, предполагает написание множества процедур утилизации, - по одной для каждого типа объектов, которые, в свою очередь, могут содержать ссылки на другие объекты. Результатом будет множество взаимно рекурсивных процедур большой сложности.

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

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

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

Оглавление книги