System Object Model

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
System Object Model (SOMObjects)
IBM SOMobjects Logo.png
Разработчик

CILabs (Apple Computer, IBM и др.)

Операционная система

Mac OS, OS/2, AIX, Windows

Последняя версия

3.0 (декабрь 1996 года)

System Object Model (SOM) — система объектно-ориентированных динамических библиотек, разработанная CILabs (IBM, Apple, OMG, Adobe, Oracle и др.). DSOM, основанная на CORBA распределенная версия SOM, позволяющая распределять объекты по различным вычислительным системам. Существуют реализации для Windows NT, MacOS, OS/2, AIX и ряда других операционных систем от IBM. Для MacOS и OS/2 существует реализация компонентной разработки приложений OpenDoc на базе SOM/DSOM.

Сравнение с другими объектными моделями[править | править исходный текст]

IBM SOM концептуально похож на Microsoft Component Object Model. Обе системы решают проблему создания стандартного формата библиотеки, которую можно было бы вызывать из более, чем одного языка. SOM считается более функциональным, чем COM. COM предлагает два способа вызывать методы объекта, и объект может реализовать один из них или оба. Первый — это динамический вызов и позднее связывание (IDispatch), и, аналогично SOM, не зависит от языка программирования. Второй способ, через частный интерфейс, использует таблицу функций, которую можно сконструировать на C, либо использовать совместимую на нижнем уровне таблицу виртуальных методов объекта C++. Используя совместимые компиляторы C++, можно объявлять частные интерфейсы как чисто виртуальные классы C++. Частные интерфейсы — это компромисс между функциональностью и производительностью. Как только интерфейс опубликован в выпущенном продукте, в него нельзя вносить изменения, поскольку приложения–пользователи интерфейса были скомпилированы под конкретное устройство таблицы на нижнем уровне. Это пример проблемы хрупкого базового класса, которая может привести к DLL hell, когда после установки новой версии разделяемой библиотеки все программы, использующие старую версию, перестают работать корректно. Чтобы избежать этой проблемы, COM разработчикам необходимо всегда помнить о том, что нельзя изменять уже опубликованные интерфейсы. Если требуется добавить новые методы или внести другие изменения, нужно определять новые интерфейсы.

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

SOM также более функционален в том, что касается полной поддержки различных ОО языков. В то время, как разработка на COM сводится к использованию урезанной версии C++, SOM поддерживает почти весь набор обычных возможностей и даже немного эзотерических. Например, SOM поддерживает множественное наследование, метаклассы и динамические вызовы. Некоторые из этих возможностей не отражены в большинстве языков, в связи с чем многие SOM/COM–подобные системы реализованы проще ценой поддержки меньшего набора языков. Полная гибкость многоязыковой поддержки была важна для IBM, в связи с необходимостью поддерживать как Smalltalk (одиночное наследование, динамическое связывание), так и C++ (множественное наследование и статическое связывание).

Наиболее заметное отличие между SOM и COM — это поддержка наследования — у COM отсутствует вовсе. Может показаться странным, что Microsoft произвела систему библиотек объектов, не поддерживающую наиболее фундаментальный принцип ООП. Главным препятствием для этого является сложность определения нахождения базового класса в системе, в то время, как библиотеки загружаются в потенциально произвольном порядке. COM требует от разработчика точно указывать базовый класс на этапе компиляции, делая невозможной вставку других наследованных классов в середину (по крайней мере, в чужие библиотеки COM).

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

Ссылки[править | править исходный текст]