Менеджер Компонентов в Mac OS: Архитектура и Принципы Работы

Введение

В программировании компьютеров Apple Macintosh, Component Manager был одним из множества подходов к повторному использованию кода, зародившихся на компьютерах Macintosh до PowerPC. Он был впервые представлен как часть QuickTime, которая оставалась наиболее активным пользователем этой технологии в классической Mac OS.

Технические детали

Компонент представлял собой фрагмент кода, предоставляющий различные функции, которые могли вызываться клиентами. Каждая функция идентифицировалась знаковым 16-битным целым числом в качестве ID-кода. Неположительные коды были зарезервированы для предопределенных функций, которые должны были пониматься всеми компонентами – открытие/закрытие экземпляра компонента, запрос о поддержке функции и т.п. Значения положительных кодов функций зависели от типа компонента. Экземпляр компонента создавался путем открытия компонента. Это вызывало функцию открытия компонента для выделения и инициализации необходимой памяти для экземпляра. Закрытие экземпляра освобождало эту память и делало недействительными все ссылки на этот экземпляр. Компоненты и экземпляры компонентов адресуются 32-битными значениями, которые не являются указателями. Вместо этого они интерпретируются как ключи во внутренние таблицы менеджера компонентов. Эти ссылки генерировались таким образом, что после того, как они становились недействительными, эти значения вряд ли снова становились бы действительными в течение длительного времени. Это минимизировало вероятность возникновения трудноуловимых ошибок из-за висячих ссылок. Компоненты идентифицировались кодами OSType, указывающими их тип, подтип и "производителя". Например, тип компонента мог быть "компрессор растровых изображений", для которого могли существовать подтипы для JPEG, H.261, Sorenson и Intel Indeo, среди прочих. Была возможность зарегистрировать несколько компонентов с совершенно одинаковыми идентификационными кодами, предоставляя альтернативные реализации одного и того же алгоритма, например, с использованием аппаратных и программных средств, компромисса между скоростью и качеством или других критериев. Приложения могли запрашивать наличие таких альтернатив и делать явный выбор между ними или позволять системе выбирать значение по умолчанию. Среди доступных опций компонент мог делегировать часть своих функций другому компоненту в качестве формы подклассинга для повторного использования кода. Также было возможно, чтобы один компонент захватил другой, что означало, что весь доступ к захваченному компоненту должен был осуществляться через захватывающий компонент.

A component was a piece of code that provided various functions that may be invoked by clients. Each function was identified by a signed 16 bit integer ID code. Non positive codes were reserved for predefined functions that should be understood by all components—open/close a component instance, query whether a function was supported, etc. The meanings of positive function codes depended on the type of component. A component instance was created by opening a component. This called the component's open function to allocate and initialize any necessary storage for the instance. Closing the instance got rid of this storage and invalidated all references to that instance. Components and component instances were referenced by 32 bit values that were not pointers. Instead, they were interpreted as keys into internal Component Manager tables. These references were generated in such a way that, once they became invalid, those values were unlikely to become valid again for a long time. This minimized the chance of obscure bugs due to dangling references. Components were identified by OSType codes giving their type, subtype and "manufacturer". For instance, a component type might be "raster image compressor", subtypes of which might exist for JPEG, H.261, Sorenson, and Intel Indeo, among others. It was possible to have multiple components registered with exactly the same identification codes, giving alternative implementations of the same algorithm for example using hardware versus software, trading off speed versus quality, or other criteria. It was possible for the applications to query the existence of such alternatives and make explicit choices between them, or let the system choose a default. Among the options available, a component could delegate parts of its functions to another component as a form of subclassing for code reuse. It was also possible for one component to capture another, which meant that all accesses to the captured component had to go through the capturing one.