Apple Macintosh бағдарламалаудағы Component Manager: кодты бөлісу әдісі, QuickTime құрамында пайда болған. Компоненттер – функцияларды қамтамасыз ететін код бөліктері.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Кіріспе
Apple Macintosh компьютерлік бағдарламалауда Component Manager – PowerPC Macintosh-қа дейінгі кезеңде пайда болған кодты бөлісудің көптеген әдістерінің бірі еді. Ол бастапқыда QuickTime құрамына енгізілді, және классикалық Mac OS жүйесінде оны ең көп пайдаланған бөлім болып қала берді.
In Apple Macintosh computer programming, Component Manager was one of many approaches to sharing code that originated on the pre PowerPC Macintosh. It was originally introduced as part of QuickTime, which remained the part of the classic Mac OS that used it most heavily.
Техникалық мәліметтер
Компонент – клиенттер шақыра алатын әртүрлі функцияларды қамтамасыз ететін кодтың бір бөлігі болды. Әрбір функция 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.