Системная объектная модель ( SOM ) — это объектно-ориентированная технология разделяемой библиотеки, разработанная IBM , которая поддерживает определение интерфейса к объекту таким образом, чтобы его интерфейс был отделен от его реализации .
DSOM , распределенный вариант на основе CORBA , позволял объектам на разных компьютерах взаимодействовать.
Библиотеку SOM можно обновить, не требуя перестройки клиентского кода. Если библиотека изменяется для добавления новых классов или методов или для изменения внутренней реализации классов или методов, программа-потребитель все равно может использовать ее без перестройки. Таким образом, SOM решает проблему хрупкого бинарного интерфейса , которая влияет на другие библиотечные технологии, такие как C++ .
SOM позволяет определять классы на одном языке программирования и использовать их на другом. Клиент может создавать и использовать объекты из представленных классов и выводить подклассы из представленных классов, даже если клиентский язык не поддерживает типизацию классов.
SOM предоставляет интерфейс прикладного программирования (API), который обеспечивает доступ к метаданным библиотеки . Каждый объект предоставляет методы, которые предоставляют имя класса и реализует ли объект определенный метод, например.
SOM предназначалась для повсеместного использования в мэйнфреймах и настольных компьютерах IBM ( OS/2 ), позволяя программам, разработанным для настольных компьютеров, использовать мэйнфрейм для обработки и хранения данных. IBM выпустила версии SOM/DSOM для OS/2, Microsoft Windows и различных разновидностей Unix (в частности, собственного AIX IBM ). В течение некоторого времени после формирования альянса AIM SOM/DSOM также использовалась Apple Computer для аналогичных целей. Наиболее широко она использовалась в их фреймворке OpenDoc , но также имела ограниченное применение в других ролях.
Возможно, наиболее широкое применение SOM в IBM было в более поздних версиях OS/2, где он использовался для большей части кода, включая Workplace Shell . Object REXX для OS/2 способен работать с классами и объектами SOM, включая WPS. [1]
SOMobjects не были полностью закрыты IBM. Они были портированы на OS/390 и до сих пор доступны в этой ОС. Документацию можно прочитать на веб-сайте IBM. [2] В 1996 году Tandem Computers Inc. приобрела технологию SOMobjects. [3] Tandem была продана Compaq, Compaq был продан Hewlett-Packard. NonStop DOM и некоторые другие технологии в конечном итоге объединились в NonStop CORBA, но текущая документация по продуктам NonStop не содержит признаков того, что технология SOM все еще поддерживает продукты NonStop.
Со «смертью» OS/2 в середине 1990-х годов, смысл существования SOM/DSOM в значительной степени исчез; если бы пользователи не запускали OS/2 на настольных компьютерах, то в любом случае не было бы универсальной объектной библиотеки. В 1997 году, когда Стив Джобс вернулся в Apple и завершил многие разработки, включая Copland и OpenDoc , SOM был заменен на Objective-C, который уже использовался в OPENSTEP (позже ставший Mac OS X). Разработка SOM/DSOM сошла на нет и больше активно не развивается, хотя он продолжает быть включенным и использоваться в системах на базе OS/2, таких как ArcaOS . [4]
Несмотря на фактическую смерть OS/2 и OpenDoc, SOM может иметь еще одну нишу: Windows и кроссплатформенная разработка. SOM 3.0 для WinNT был доступен в декабре 1996 года. Причины отсутствия продвижения в этих направлениях выходят за рамки проблем принятия рынком. Они включают возможности, упущенные IBM , [5] и разрушительные несовместимые изменения:
Существуют два проекта реализаций SOM с открытым исходным кодом. Один из них — Netlabs Object Model (NOM), который технически то же самое, но несовместим на уровне двоичного кода. Другой — somFree, который представляет собой проект IBM SOM в чистой комнате и совместим на уровне двоичного кода. [ необходима цитата ]
SOM можно сравнить с скомпилированными библиотеками: [9]
По состоянию на 2015 год большая часть информации в связанной таблице применима к современным версиям, за исключением Objective-C 2.0, получившего так называемые нехрупкие переменные экземпляра. Некоторые решения остались экспериментальными: SGI Delta/C++ или Sun OBI. Большинство подходов, основанных на одном языке программирования, были постепенно прекращены или никогда не использовались активно таким же образом. Например, плагины браузера Netscape Plugin Application Programming Interface ( NPAPI ) изначально были написаны с использованием Java API (LiveConnect), но позже Java Virtual Machine (JVM) была исключена из цепочки. Это можно рассматривать как замену Java на Cross Platform Component Object Model ( XPCOM ). Common Lisp Object System (CLOS) и Smalltalk не известны как звенья цепи, как Java в LiveConnect. Objective-C также не очень известен в этой роли и не известен, чтобы рекламировался таким образом, но его среда выполнения является одной из самых дружественных для подобных вариантов использования.
Generic C++ все еще используется в Qt и K Desktop Environment ( KDE ). Qt и KDE известны тем, что описывают усилия, необходимые для поддержания двоичной совместимости без специальной поддержки в инструментах разработки. [10]
GObject нацелен только на то, чтобы избежать зависимости от компилятора C++, но проблемы RRBC те же, что и в общем C++.
Без специальной среды выполнения многие другие языки программирования будут иметь те же проблемы, например, Delphi , Ada . Это можно проиллюстрировать так называемым беспрецедентным подходом, который был использован для создания бинарной совместимости Delphi 2006 Delphi 2007: Как добавить "опубликованное" свойство, не нарушая совместимость с DCU Архивировано 2015-12-08 на Wayback Machine
Objective-C является наиболее перспективным конкурентом SOM (хотя и не рекламируется активно как многоязыковая платформа), и SOM предпочтительнее сравнивать с Objective-C, а не с COM, как это исторически сложилось. С нехрупкими переменными экземпляра в Objective-C 2.0 это лучшая альтернатива среди активно поддерживаемых.
COM , XPCOM активно используются, но они управляют только интерфейсами, а не реализациями, и, таким образом, не находятся на том же уровне, что и SOM, GObject и Objective-C . Windows Runtime при более близком рассмотрении ведет себя во многом как COM. Описание его метаданных основано на .NET, но поскольку WinRT не содержит специальной среды выполнения для решения проблем RRBC, как в Objective-C или SOM, пришлось применить несколько ограничений, которые ограничивают WinRT на процедурном уровне:
Система типов (C++/CX)
Компоненты среды выполнения Windows - Компоненты среды выполнения Windows в мире .NET
SOM часто сравнивают с компонентной объектной моделью (COM). Оба поддерживают формат библиотеки, который может использоваться из более чем одного языка.
Некоторые считают SOM более надежным, поскольку он поддерживает только нейтральный к языку механизм вызова, который похож на позднее связывание COM . COM также поддерживает раннее связывание , также известное как пользовательский интерфейс, который менее безопасен, но более производительен. Он позволяет клиенту получать доступ к объекту через таблицу функций, которая совместима с C и, следовательно, совместима с двоичной компоновкой виртуальной таблицы объектов C++ (по крайней мере, в компиляторе C++ от Microsoft). С совместимым компилятором C++ пользовательский интерфейс может быть определен как чистый виртуальный класс C++. Интерфейс может быть вызван любым языком, который может вызывать функции C через указатель.
Риск пользовательского интерфейса заключается в том, что несовместимость может привести к неопределенному поведению . В частности, если версия объекта опубликована с измененным пользовательским интерфейсом, клиент может выйти из строя. Это пример проблемы хрупкого базового класса . Чтобы предотвратить эту проблему, правило для разработки COM заключается в том, что после публикации пользовательский интерфейс не может быть изменен. Чтобы добавить или изменить открытые функции объекта, он может реализовать дополнительные пользовательские интерфейсы.
SOM избегает этой проблемы, предоставляя только позднее связывание – позволяя компоновщику времени выполнения перестраивать таблицу на лету. Таким образом, изменения в базовых библиотеках разрешаются при их загрузке в программы.
SOM более надежен с точки зрения поддержки объектно-ориентированных (OO) функций. В то время как COM по сути определяет урезанную версию C++ для программирования, SOM поддерживает почти все общие функции. Он также поддерживает некоторые менее общие функции, такие как множественное наследование , метаклассы и динамическая диспетчеризация , что привело к тому, что большинство систем, подобных SOM/COM, стали проще за счет поддержки меньшего количества языков. Поддержка нескольких языков была важна для IBM, поскольку они хотели поддерживать как Smalltalk ( единичное наследование и динамическая диспетчеризация ), так и C++ ( множественное наследование и фиксированная диспетчеризация).
Заметным отличием является поддержка наследования. COM этого не делает. Хотя может показаться странным, что Microsoft создала технологию библиотеки объектов, которая не может поддерживать такую фундаментальную концепцию OO-программирования; главная причина в том, что трудно узнать, где в памяти находится базовый класс, а библиотеки загружаются в неизвестном во время проектирования порядке. COM требует, чтобы программист указывал точный базовый класс во время компиляции, что делает невозможным вставку других производных классов в середину; по крайней мере, в других библиотеках COM.
Вместо этого SOM использует алгоритм, который ищет потенциальные базовые классы, следуя дереву наследования и останавливаясь на первом совпадающем. Это идея наследования в большинстве случаев. Недостатком этого подхода является то, что новые версии этого базового класса могут перестать работать, даже если API останется прежним. Такая возможность существует в любой программе, не только в тех, которые используют общую библиотеку, но проблема может стать трудноразрешимой, если она существует в чужом коде. В SOM единственным решением является тестирование новых версий библиотек.
Хотя IBM противопоставляла SOM и COM, они не были взаимоисключающими. В 1995 году Novell внесла технологию ComponentGlue [11] в OpenDoc для Windows. Эта технология предоставила различные средства для интеграции между компонентами COM и SOM. В частности, объекты SOM могут быть доступны приложениям OLE2 либо с помощью моста позднего связывания (на основе IDispatch), либо с помощью интерфейсов COM, имеющих более высокую производительность. По сути, классы SOM реализуют интерфейсы COM таким образом.
Аналогичные технологии, такие как Distributed Objects Everywhere , также поддерживают полное наследование. Portable Distributed Objects избежали этих проблем с помощью сильной системы управления версиями, что позволило авторам библиотек отправлять новые версии вместе со старыми, тем самым гарантируя обратную совместимость за счет дискового пространства.