Чтение онлайн

Не попадайте в эту ловушку. Пусть данные представляют сами себя, или, как сказал Лори Андерсон (Laurie Anderson) в книге "Большая наука" (Big Science)

Let X = X

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

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

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

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

Или, крепко возьмитесь левой рукой прежде чем отпустить правую!

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

Объектные проекты нацелены на создание формализованного Хода Конем ("вилки") с использованием подхода, который явно связывает объекты реального мира с жизнеспособной семантикой системы посредством объектных языков программирования (будь это Eiffel или генератор кода UML). При разработке этих проектов их создатели стремятся представить все, что есть сейчас в реальном мире, а не будет завтра, когда система будет использоваться. Главное отличие в том, что завтра система будет существовать в мире пользователя -- сегодня это не так. Поэтому аналитики регулярно создают маленькие картинки мира пользователя в будущем, которые содержат все, кроме самой компьютерной системы, которая является центром всего сценария.

Тем не менее, внутренний проект системы также испытывает затруднения из-за недостаточного представления самой системы. Кто-то мог бы сказать, что система реального мира и внутренняя система -- это одно и то же как в реальном, так и в абстрактном мирах, и, следовательно, эта идентичность в объектных проектах формирует появление "Хода Конем" в наиболее фундаментальной форме.

Вот два глубоких вопроса, возникающих при поиске объектов и попытках найти их взаимосвязи:

Кто кого порождает? Кто чьи методы использует?

Имея в проекте чистый класс System (Система), гораздо легче построить иерархию наследования и увидеть, откуда приходят такие вещи как GUI и ввод/вывод на ленту, не говоря уже о событиях, запускаемых по таймеру! Это не означает, что на более поздней стадии проектирования функциональность нельзя поместить в специализированные классы, но в проекте это дает реальности мира пользователя равный вес с реальностью системы, поэтому результат будет удовлетворять обоим критериям.

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

Конечно, потребность в классе System (Система) исчезает, если кому-то нужно просто моделирование, а не автоматизация бизнес-процессов, в которых не представлены управляющие системы. Каким мог бы быть подход в таком случае? Здесь мы напираем на то, что проектирование, формируемое стратегией картостроения, включает в себя больше, чем просто набор процедурных действий. Это означает очерчивание проблемы, прояснение желаний, нахождение точки оптимального приложения сил между динамикой проблемы и семантикой системы. Если ваш проект не получает преимуществ от класса System (Система), не используйте его!

На рынке имеется ряд продуктов, которые на основе различных стратегий обнаруживают утечки памяти в приложениях. Утечка памяти -- это то, что случается, когда программа запрашивает блок памяти из кучи (используя, например, malloc в Cи под UNIX или DOS , или оператор new в C++), а затем забывает вернуть его обратно по своему завершению. Иногда это приводит к нарушению работы других процессов, работающих на той же платформе, поскольку некоторые операционные системы позволяют одному процессу захватить всю имеющуюся память системы и файл подкачки.

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

Поэтому утечки памяти -- это Плохая Вещь.

Это причина того, почему люди продают, и покупают, детекторы утечки памяти. Неприятность в том, что утечки -- это симптом проблемы, а не причина проблемы. Не так трудно вызвать free или удалить объекты, которые больше не нужны. Применение delete к коллекции указателей на активные объекты -- вот опасное занятие, как и перезаписывание их адресов. Что если эти объекты, скажем, зарегистрировали функции обратного вызова (callbacks) в GUI ? Как же их освободить? Деструкторы вне контроля -- это программист вне контроля. Если программист не может продемонстрировать контроль над объектами, которого достаточно для избежания утечек памяти, то как мы можем думать, что правильно еще хоть что-нибудь?

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

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