 |
The Russian Electronic Developer Magazine |
 |
Русский электронный журнал разработчика |
     |
|
|
The Russian Electronic Developer Magazine |
|
Русский электронный журнал разработчика |
|
|
О системно-объектной модели SOM, на которой основана оболочка OS/2(С) СК Пресс 5/96
PC Magazine, October 10, 1995, p. 513
Габриель Ганьон - менеджер в области информационных технологий (г. Бостон)
Технология объектно-ориентированного программирования сулит много преимуществ не только программистам, но и конечным пользователям. И далеко не последнее из них - возможность создавать прикладные программы из готовых модулей. Если вам до сих пор не доводилось сталкиваться с OS/2, вы можете не знать, что Workplace Shell (оболочка рабочего места) представляет собой объектно-ориентированный комплекс и что все ее объекты - папки, блокноты, принтеры, шаблоны и т.п. - суть готовые компоненты, которые вы можете настраивать и интегрировать в свои прикладные программы.
Оболочка Workplace Shell (WPS) основана на системно-объектной модели (System Object Model - SOM) IBM - технологии, специально разработанной для решени таких проблем, как жесткая привязка объектов к их клиентам и необходимость использования одного и того же языка программирования. Объекты Workplace Shell работают в среде SOM, доступ в которую можно реализовать почти на всех языках программирования, где предусмотрены внешние процедуры, в том числе и на REXX. Хотя с помощью REXX невозможно создать класс WPS или разбить его на подклассы - для этого вам понадобитс отдельный компилятор SOM,- вы тем не менее можете создавать и уничтожать объекты WPS и выполнять практически все остальные операции с ними. Такие возможности приходятся очень кстати, если вы системный администратор, которому нужно кофигурировать несколько рабочих станций.
SOM - не связанная ни с одним конкретным языком объектно-ориентированная технология для создания, хранения и использования двоичных бибилиотек классов. Ключевые слова здесь "двоичные" и "не связанная ни с одним конкретным языком". Хотя многие считают OS/2 технологией прошлого, модель SOM на самом деле представляет собой одну из наиболее интересных новых разработок в области компьютерной индустрии на сегодняшний день. Объектно-ориентированное программирование (ООП) заслужили безоговорочное признание в качестве основной парадигмы, однако его применению в коммерческом программном обеспечении препятствуют отсутствие в языках ООП средств дл обращения к библиотекам классов, подготовленным на других языках, и необходимость поставлять с библиотеками классов исходные тексты. (Многим независимым разработчикам библиотек классов приходитс продавать заказчикам исходные тексты, поскольку разные компиляторы по-разному отображают объекты.)
Как мы увидим в дальнейшем, SOM снимает и эти ограничения, и те, что налагаются жесткой привязкой объекта к его клиентам на уровне двоичных кодов, которая выступает помехой для многих языков ООП - таких как C++, - где сообщения и методы связываютс статически во время компиляции, а не во врем выполнения. Кроме того SOM представляет интерес не только для разработчиков OS/2. В настоящее время среда выполнения SOM поставляется в комплекте OS/2, и системы AIX корпорации IBM, особо продается версия для Windows. Архитектура составных документов OpenDoc, используема Apple, также основана на SOM. Настоящий потенциал SOM заключается в ее совместимости практически с любой платформой и любым языком программирования. SOM соответствует спецификации COBRA (Common Object Request Broker Architecture - Архитектура посредника стандартного объектного запроса), которая определяет стандарт условий взаимодействия между прикладными программами в неоднородной сети.
Спецификация COBRA была разработана консорциумом Object Management Group (Группа управления объектами), объединяющим более 300 компаний - поставщиков программного обеспечения и оборудования и потребителей их продукции. В консорциум входят все основные компьютерные фирмы, что определяет ее значительное влияние. Даже корпорация Microsoft - член консорциума, хотя ее участие находится под вопросом, так как она занимается разработкой своего собственного стандарта - Модели составных объектов (Component Object Model - COM), - который по всей видимости со временем составит конкуренцию COBRA.
Спецификация COBRA является частью более широкого стандарта для распределенной обработки, называемого Архитектурой управления объектами (Object Management Architecture - OMA). COBRA определяет архитектуру Посредника объектного запроса (Object Request Broker - ORB), который управляет взаимодействием между объектами и прикладными программами. Через ORB можно посылать запросы между процессами, работающими на одной машине, или между машинами в сети. DSOM (Distributed SOM) - структура распределенных объектов SOM, входящая в пакет SOMObjects Developer Toolkit, поставляемый IBM, - представляет собой реализацию COBRA ORB.
Все вышесказанное означает, что SOM, или точнее DSOM, - достаточно перспективная технология для работы с распределенными объектами и проявление общей тенденции в компьютерной индустрии к более тесному сотрудничеству. Многие считают спецификацию COBRA единственным действительно работоспособным стандартом, связывающем различные платформы и операционные системы. И SOM - достойная реализация этого стандарта, которую вы можете использовать уже сегодня.
SOM - это объектная модель, которая имеет структуру классов и предоставляет механизм для независимой разработки библиотек классов на разных языках программирования и для отделения реализации класса от клиентских программ, использующих эту реализацию. SOM не является объектно-ориентированным языком в полной мере, но соответствует таким принципам объектно-ориентированного программирования, как инкапсуляция (скрытое описание реализации объекта), наследование и полиморфизм.
В модели SOM классы представляют шаблоны дл объектов, определяющие их возможные свойства и поведение. Объекты - особые экземпляры классов. Однако, в отличие от классов в C++, классы SOM сами являются объектами, и в этом смысле они похожи на классы в "истинно" объектно-ориентированных языках - таких как Smalltalk. В то время как классы C++ - структуры этапа компиляции, которые исчезают во врем выполнения, классы SOM существуют в качестве классов-объектов на этапе выполнения. Поскольку все объекты SOM должны быть экземплярами классов SOM, необходима некая структура, экземплярами которой будут сами классы. Для этого SOM использует "метаклассы". (Метаклассы служат шаблонами для классов точно так же, как классы служат шаблонами для объектов.) Одно из преимуществ существования классов SOM в качестве классов-объектов заключается в том, что можно получать и обновлять информацию о классах динамически, во врем выполнения.
Модель SOM организует некий промежуточный слой между объектами и их клиентами, тем самым обеспечива свободный доступ к библиотекам классов. Классы SOM, или точнее, интерфейсы с ними, создаются с использованием основанного на спецификации COBRA языка определени интерфейсов (Interface Definition Language - IDL). IDL - это близкий к Cи, разработанный специально дл определения интерфейсов классов, независимых от языков. Применение IDL позволяет отделить интерфейс объекта от его реализации. При такой организации пользователь класса и разработчик его реализации вовсе не обязаны использовать один и тот же язык. После того как класс SOM определен, компилятор принимает IDL-текст и генерирует соответствующие привязки для текста реализации и заголовки для файлов клиента. (Уже существуют компиляторы DirectToSOM, которые минуют этап создания и компиляции IDL-текста, но конечный результат остается тем же.) В настоящий момент корпорация IBM поставляет привязки для классов, реализованных на C и C++, и со временем планирует выпустить их дл Smalltalk, OORexx и COBOL. Независимые фирмы также имеют подобные разработки. Для тех, кто хочет создать свои собственные привязки, IBM поставляет оболочку Emitter, входящую в пакет SOMObjects Developer Toolkit.
Здесь важно осознать, что при использовании SOM, объекты и их клиенты привязываются не друг к другу, а к интерфейсу. Это означает, что пока интерфейс с объектом остается неизменным, реализация его может изменяться, не затрагивая при этом клиентов объекта. Такой механизм преодолевает ограничения, присущие языкам со статической привязкой, таким как C++ или Object Pascal. В C++ классы и их клиенты жестко сцеплены (т. е. скомпилированный код клиента содержит константы, величины которых зависят от того, как организованы используемые ими классы). В результате вы не можете изменить классы без глобальной перекомпиляции при этом всех их клиентов. Для языков с динамическим связыванием - таких как Smalltalk или Objective C - это не представляет проблемы, однако для Cи++ может обернуться полным кошмаром. Данная ситуация означает, что, если вы измените один из базовых классов, добавив, к примеру, виртуальную функцию, вам придетс перекомпилировать не только клиентов того класса, который вы изменили, но и клиентов всех классов, порожденным данным (не в этом ли простая причина того, что C++ до сих пор не завоевал весь мир.) Поскольку модель SOM отделяет класс от его клиентов, она позволяет реализовать на C++ динамическую связь с объектами, как это делает Smalltalk.
Еще одно примечательное свойство SOM состоит в том, что она предусматривает наследование интерфейсов: подклассы SOM наследуют все методы, определенные в интерфейсах их родительских классов, даже если реализованы они на других языках.
Модель SOM также поддерживает множественное наследование (возможность производить подкласс из нескольких родительских классов). Одна из возникающих при этом проблем в том, что два или более родител могут использовать описания одного и того же метода, и, поскольку подкласс может унаследовать этот метод только от одного родителя, приходится искать способ разрешени конфликта. По умолчанию SOM использует левосторонний приоритет, заключающийся в том, что родитель, находящийся в иерархии слева, оказывается "главнее". Но если вам угодно использовать другое правило разрешения подобных ситуаций, вы можете создать новый метакласс и заменить механизм наследования, установленный SOM. Конечно, таким путем вы можете привести иерархию объектов в полный беспорядок, однако приятно знать, что в вашем распоряжении есть весьма гибкие средства.
За гибкость, предоставляемую SOM, приходится кое-чем расплачиваться. Дополнительный слой косвенных связей плюс использование метаклассов вызывают некоторое снижение производительности - в отдельных прикладных программах до 20%, - так что лучше обойтись без SOM в тех случаях, когда не нужна независимость от языка или когда вы часто обращаетесь к коротким методам. Однако Workplace Shell обычно обращается к длинным методам, что не приводит к значительным потерям в производительности.
Для того, чтобы работать с SOM эффективно, вам нужно познакомиться с иерархией классов SOM и с тем, какое место в ней занимает WPS. Эти взаимосвязи показаны ниже.
На вершине иерархии объектов SOM находится SOMObject - корень всех классов SOM. Все классы, в том числе и и классы WPS, прямым или косвенным образом наследуют свои свойства и поведение от SOMObject.
SOMObject
---------
|_____________________________________
| | |
SOMClass SOMClassMgr WPObject
-------- ----------- --------
__________________________________|______
| | |
_ WPAbstract _ WPFileSystem _ WPTransient
| ---------- | ------------ | -----------
|- WPClock |- WPFolder |- WPJob
|- WPCountry | WPDesktop |- WPPort
|- WPDisk | WPDrives |- WPMinWindow
|- WPKeyboard | WPStartUp |- WPQueueDriver
|- WPMouse | WPTemplates |- WPCnpView
|- WPPalette | WPMinWinViewer |- WPDiskCV
| WPColorPalette | WPFindFolder |- WPFolderCV
| WPFontPalette | WPNetGroup |- WPFilter
| WPSchemePalette | WPNetwork |- WPFinder
|- WPProgram | WPServer
|- WPShadow | WPShareDir
| WPNetLink |- WPDataFile
|- WPShredder WPBitmap
|- WPSound WPIcon
|- WPSpecialNeeds WPPointer
|- WPSpooler WPProgramFile
|- WPSystem WPCommandFile
|- WPPrinter WPMet
|- WPPower WPPif
|- WPTouch WPPrinterDriver
|- WPFntpnl
|- WPWinConfig
Корень всех классов SOM - SOMObject. Все классы прямым или косвенным образом наследуют свои свойства и поведение от SOMObject. Поскольку каждый класс представлен классом-объектом, а каждый класс-объект в свою очередь должен быть экземпляром метакласса (вспомните, что метаклассы являются шаблонами дл классов, а классы - шаблонами для объектов), то и класс SOMObject - экземпляр метакласса SOMClass.
Как мы уже отметили, и сами метаклассы предствляют собой объекты, поэтому дальше возникает вопрос: экземплярами чего являются метаклассы? Если строго следовать логике, ответом должен быть мета-метакласс, и так можно продолжать до бесконечности. Однако необходимо же с чего-то начать. И модель SOM определяет, что метаклассом всех метаклассов будет SOMClass (таким образом, SOMClass попадает в забавное положение, являясь экземпляром самого себя). SOMClass также является родительским классом для всех метаклассов. Все метаклассы порождаются от SOMClass. Неудивительно, если вы сейчас сбиты с толку. Главное, что нужно помнить, - это то, что методы, вызываемые из классов, берутся в SOMClass, а методы, вызываемые из объектов, - в SOMObject.
Другой важный подкласс SOMObject - SOMClassMgr. Этот класс ведет учет всех классов SOM, существующих в среде выполнения SOM, и помогает загружать и выгружать библиотеки классов. (Библиотеки классов SOM в это врем хранятся в виде DLL.)
SOMObject, SOMClass и SOMClassMgr, вместе с функциями инициализации и настройки среды выполнени SOM хранятся в SOM.DLL, который OS/2 загружает при своей инициализации. Когда запускается среда исполнения SOM, создается экземпляр класса SOMClassMgr, который продолжает существовать на всем протяжении работы OS/2. При первой ссылке на какой-либо класс объект SOMClassMgr загружает соответствующий DLL и создает экземпляр этого класса.
Продолжая спускаться по иерархии объектов SOM, мы войдем в область Workplace Shell, о чем станет ясно из префикса WP, присущего всем классам WPS. На вершине дерева WPS находится корень всех объектов WPS - WPSObject. Свойства, присущие всем объектам WPS, такие как название или пиктограмма, наследуются от WPSObject. Он порождает три основных класса - WPFileSystem, WPAbstract и WPTransient - в которых объекты WPS группируются по типу используемой ими памяти. Все объекты WPS попадают в один из этих трех классов.
Интересные ссылки:
Комментариев к странице: 0 | Добавить комментарий
Редактор: Дмитрий Бан
Оформление: Евгений Кулешов