Xreferat.com » Рефераты по информатике и программированию » Статические методы против виртуальных методов

Статические методы против виртуальных методов

Это весьма непростой и спорный вопрос. В "чистых" языках, использующих подход OOP, статические методы не существуют; все методы являются виртуальными. И сторонник "чистого" подхода OOP мог бы сказать, что все методы в нашей иерархии объектов должны быть виртуальными именно по той причине, что виртуальные методы стоят на первом месте. Такой аргумент можно было бы признать справедливым, но еще больше истины в том, что делать все методы только виртуальными просто непрактично - по крайней мере, тогда, когда Вы программируете на Turbo Pascal.

На наш взгляд, имеются два убедительных довода в пользу того, чтобы везде, где это только возможно, использовать статические методы. Во-первых, интеллектуальный компоновщик Turbo Pascal не может отменять неиспользуемые виртуальные методы, а только неиспользуемые статические методы; простой акт ввода объекта данного типа приводит к тому, что в программу должны быть скомпонованы все виртуальные методы этого объекта. И во-вторых, чем больше виртуальных методов имеет объект, тем обширнее его таблица виртуальных методов VMT: объект, имеющий 100 виртуальных методов, использовал бы более 400 байт пространства в сегменте данных. В системе Object Professional нет ни одного объекта, который бы имел так много виртуальных методов, но если бы все методы были виртуальными, в ней бы имелся не один такой объект.

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

а) если мы знаем, что он должен быть отменен объектом-потомком,

б) если метод предназначен для того, чтобы быть отмененным, и для этой цели и существует,

в) если в самой природе метода заложена возможность того, что желательно его отменить в объекте-потомке.


Указатели процедур против производных типов.


Еще один концептуально спорный вопрос. Рассмотрим случай, когда для некоторого объекта необходимо обеспечить средство, позволяющее программисту передавать такую информацию для объекта, которая не всегда бывает известна на момент компилирования. Наглядным примером такого объекта является "PickList" ("Список_Подбора") в модуле OPPICK: он должен обеспечить средство, которое предоставит Вам возможность "сообщить" ему, какие элементы имеются в списке подбора.

Сторонник "чистого" метода мог бы сказать, что для решения этой проблемы следует обеспечить фиктивный виртуальный метод, который, как предполагается, будет возвращать необходимую информацию, и пусть потом программист создает производный тип, который отменяет этот метод. Но такой подход порождает две проблемы. Первая заключается в том, что было бы досадно, если бы КАЖДЫЙ раз, когда возникает потребность использовать, например, объект PickList, пришлось создавать производный тип, особенно в том случае, если все, что Вам действительно требуется - это написать функцию для восстановления строки на основе номера элемента. Вторая проблема состоит в том, что при этом в большинстве случаев исключается возможность использования одного и того же объекта PickList для отображения на экране различных списков.

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


Конструкторы и деструкторы.


В системе Object Professional в соответствии с соглашениями фирмы Borland принято для конструкторов использовать имя "Init" ("Начальный"), а для деструкторов - имя "Done" ("Законченный"). Большинство объектов также имеет конструктор с именем "Load" ("Загрузка"), который используется для загрузки объекта из потока (еще больше на потоках через момент ?) - в соответствии с другим соглашением фирмы Borland.

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

Конструктор Init всегда принимает столько параметров, сколько возможно. Если в определенных обстоятельствах желательно передать больше параметров, существует второй конструктор с именем "InitCustom" ("Начальная_Настройка"), который их принимает (дополнительно к параметрам, которые переданы конструктору Init). В объекте, имеющем конструктор InitCustom, конструктор Init обычно используется для вызова конструктора InitCustom, который, в свою очередь, по умолчанию передает значения туда, где это необходимо.

Существует несколько объектов, которые имеют также и другие конструкторы - например, "MemoFile" ("Файл_Памяти") (модуль OPMEMO) и PickList (модуль OPPICK) - но при этом в большинстве случаев их имена начинаются с "Init", и они принимают такие же параметры, как и конструктор Init.


Использование динамически распределяемой области.


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

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

Теперь перейдем к менее пессимистичному и более общему вопросу. Модуль OPROOT, который используется большинством других модулей, содержащих объекты, устанавливает функцию ошибки динамически распределяемой области, которая "отвечает" за то, чтобы все аварийно завершившиеся вызовы New или GetMem возвращали "пустое" значение ("Nil"). Если необходимо, Вы можете отменить этот режим путем установки собственной функции ошибки динамически распределяемой области, но прежде чем это сделать, необходимо убедиться, что Вы ясно себе представляете возможные последствия. Если это только возможно, мы рекомендуем Вам писать свою программу так, чтобы она работала при этих условиях. Единственное, что Вы можете сделать, чтобы облегчить свою работу, это использовать функции GetMemCheck и FreeMemCheck в модуле OPROOT всякий раз, когда Вам необходимо разместить память или аннулировать размещение памяти из динамически распределяемой области; это то, что могут делать все Ваши объекты. Подробные сведения об использовании этих функций приведены в документации, описывающей модуль OPROOT.


Обработка ошибок.


Все объекты более высокого уровня в библиотеке построены так, чтобы выдавать сообщения обо всех ошибках, которые встречаются после того, как объект был введен в центральную программу обработки ошибок. Эта программа обработки ошибок передает как код ошибки, так и (обычно) принятое по умолчанию сообщение об ошибках, которое позволяет программе обработки ошибок вывести на экран либо типовое сообщение об ошибках, либо сообщение, модифицированное в соответствии с потребностями пользователя. Ошибки, которые встречаются в конструкторах (прежде чем имеется возможность указать программу обработки ошибок), хранятся в глобальной переменной InitStatus, объявленной в модуле OPROOT. Более подробные сведения, касающиеся способов обработки ошибок, приведены в документации, описывающей объект "CommandWindow" ("Окно_Команд") (модуль OPWINDOW) и в приложении D ("Коды ошибок").


Обработка команд и клавиатуры.


Все объекты в библиотеке, которые действуют на основе команд, вводимых с клавиатуры, используют объект с именем "CommandProcessor" ("Командный_Процессор") для того, чтобы преобразовать нажатия на клавиши в команды. Для того, чтобы это было возможно, соответствующий объект передает объекту CommandProcessor таблицу команд, представляющую собой массив особого формата, который устанавливает зависимости между последовательностями клавиш и командами. Каждая команда в библиотеке соответствует уникальному коду. Использование кодов команд и таблиц команд не только позволяет программе во время своего выполнения модифицировать и добавлять назначения клавиш, но также и создавать отдельные программы конфигурирования, которые позволяют пользователю модифицировать назначения. Подробные сведения, касающиеся обработки команд, приведены в документации, описывающей модуль OPCMD.

Объект CommandProcessor также реализует некоторые программные средства обращения к подпрограммам ("hook"), причем наиболее важное из них обеспечивает возможность указать, какая подпрограмма должна быть вызвана в тот момент, когда пользователь нажмет на соответствующую клавишу. Это средство позволяет выполнять "фоновые задачи" в то время, пока ввод команды с клавиатуры еще не произведен.


Цвета экрана и объекты ColorSet.


В системе Object Professional все объекты, которые выполняют экранный ввод/вывод ("I/O" - от "input/output"), разработаны так, чтобы облегчить написание программ, автоматическ учитывающих различия между цветными и монохромными системами. Поэтому когда объекту необходимо указать атрибуты отображения информации на экране, этот объект запрашивает два атрибута: один для цветных систем и другой - для монохромных. После этого объект будет использовать простую подпрограмму в модуле OPCRT для того, чтобы выбрать соответствующий атрибута отображения в данной ситуации.

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

Если Вам нужна помощь с академической работой (курсовая, контрольная, диплом, реферат и т.д.), обратитесь к нашим специалистам. Более 90000 специалистов готовы Вам помочь.
Бесплатные корректировки и доработки. Бесплатная оценка стоимости работы.

Поможем написать работу на аналогичную тему

Получить выполненную работу или консультацию специалиста по вашему учебному проекту
Нужна помощь в написании работы?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Пишем статьи РИНЦ, ВАК, Scopus. Помогаем в публикации. Правки вносим бесплатно.

Похожие рефераты: