مدل شیء مؤلفه
مدل شیء مؤلفه با کوته‌نوشت COM یک استاندارد واسط دودویی برای مولفه‌های نرم‌افزاری است که توسط شرکت مایکروسافت در سال ۱۹۹۳ (سال ۱۳۷۲ شمسی) معرفی شد. از این فناوری برای ایجاد توانمندی «ارتباط بین‌پردازه‌ای» در ایجاد شیء در بسیاری از زبان‌های برنامه‌نویسی استفاده می‌شود. COM مبنای چندین فن‌آوری و چارچوب دیگر مایکروسافت است، مثلاً , , , ActiveX, , , Windows shell, DirectX, ، و براساس COM هستند. ماهیت COM ایجاد یک روش «خنثی از نظر زبان» برای پیاده‌سازی اشیایی است که قابلیت استفاده در محیطی را دارند که با محیطی که در آن ایجاد شده‌اند متفاوت است، یعنی حتی می‌توان در محدودهٔ بین ماشینی از آن استفاده کرد. برای مولفه‌هایی که بخوبی نوشته شده باشند، COM امکان استفاده مجدد از اشیا را بدون هیچ دانشی از پیاده‌سازی درونی آن‌ها می‌دهد، زیرا این فن‌آوری پیاده‌سازهای مولفه را مجبور می‌کند تا «های خوش‌تعریف» تهیه کنند، که این واسط‌ها از پیاده‌سازی جدا هستند. معانی تخصیص در زبان‌های مختلف متفاوت است، اما این موضوع به این صورت سازگارسازی می‌شوند که اشیا «خودشان» مسئول ساخت خودشان باشند و از بین بردن آن‌ها از طریق شمارش ارجاع انجام می‌شود. بین واسط‌های متفاوت یک شیء از طریق شگرد QueryInterface به دست می‌آید. شگرد ارجح «ارث‌بری» در COM، ساخت زیرشیءهایی است که به آن‌ها «تماس» شگردی واگذار می‌شوند.
COM یک فن‌آوری واسط است که به عنوان یک "فقط استاندارد" در مایکروسافت ویندوز و اپل ۱٫۳ و سپس در افزونه‌های واسط برنامه‌نویسی کاربردی (API) تعریف و پیاده‌سازی شده‌است. در API فقط بخشی از کل واسط COM پیاده‌سازی می‌شود. در بعضی از کاربردها، COM تاحدی به‌وسیله چارچوب دات‌نت مایکروسافت جایگزین شده‌است، و در پشتبانی از خدمات وب توسط (WCF) جایگزین شده‌است. با این حال، اشیای COM را می‌توان با همه زبان‌های دات‌نت، از طریق در دات‌نت استفاده کرد. DCOMهای شبکه‌ای از دودویی استفاده می‌کنند، درحالیکه WCF (بنیاد ارتباط ویندوز) استفاده از پیام‌های SOAP که مبتنی بر XML اند را تشویق کرده‌است. COM به دیگر فن‌آوری‌های واسط نرم‌افزار مولفه، مثل CORBA، و بسیار شبیه است، اگرچه هرکدام از آن‌ها نقاط قوت و ضعف خودشان را دارند. برخلاف C++، در COM یک واسط دودویی کاربردی پایدار (ABI) فراهم شده‌است، و این واسط بین انتشارهای مختلف کامپایلر، تغییر نمی‌کند. این موضوع واسط‌های COM را برای کتابخانه‌های شیءگرای C++ جذاب ساخته‌است؛ زیرا این واسط‌ها باید توسط کارخواه‌های کامپایل شده توسط نسخه‌های کامپایلر مختلف استفاده شوند.
الگوی COM به منظور توانمندسازی ارتباطات بین پردازشی و ساختن اشیاء به صورت پویا، برای تعداد زیادی از زبان‌های برنامه‌نویسی مورد استفاده قرار گرفته‌است. اصطلاح COM در صنعت توسعه نرم‌افزاری مایکروسافت، به عنوان چتری که دربرگیرنده فناوریهای زیرمی‌باشد مورد استفاده قرار می‌گیرد.
نکته: هرگز نباید با قالب پروندهای COM، که پسوندی برای یک نوع از پرونده‌های اجرایی می‌باشد، اشتباه گرفته شود.
مولفه‌های COM و ActiveX به صورت کد محلی در ماشین کاربر اجرا می‌شوند، و هیچ جعبه شنی در اینجا وجود ندارد. درنتیجه محدودیت‌های کمی روی این موضوع که کد چه می‌تواند انجام دهد وجود دارد. تلاش‌های قبلی برای توکارسازی مولفه‌های ActiveX در صفحات وب با اینترنت اکسپلورر منجر به مسائلی در زمینه سرایت بدافزار شده‌اند. مایکروسافت مشکل با ActiveX را در سال ۱۹۹۶ تشخیص داد، موقعی چارلز فیتزجرالد گفته بود «ما هیچ وقت ادعا نکرده‌ایم که ActiveX به صورت ذاتی امن است». ورژن‌های جدید اینترنت اکسپلورر قبل از نصب کنترل‌های ActiveX از کاربر اجازه می‌گیرند، و این موضوع به کاربر امکان آن را می‌دهد تا اجازه نصب کنترل‌ها از سایت‌هایی که کاربر به آن‌ها اعتماد ندارد، را ندهد. کنترل‌های ActiceX توسط «امضای دیجیتال» امضا شده‌اند، تا درستی و صحت آنها تضمین گردد. این موضوع مقدور هست که همه کنترل‌های ActiveX را غیرفعال کنیم، یا فقط تعدادی اندکی که انتخاب شده‌اند را مجاز بدانیم. «پشتیبانی شفاف برای سرورهای خارج‌ازفرایند COM» هم امنیت نرم‌افزار را، در قالب جداسازی فرایندها، افزایش می‌دهد. این موضوع برای جداسازی زیرسامانه‌های برنامه‌کاربردی بزرگ به فرایندهای مجزا می‌تواند مفید باشد. انزوای فرایند، خرابی حالت در یک فرایند را، از تأثیر مخرب در درستی دیگر فرایندها، محدود می‌کند، زیرا آنها فقط از طریق واسط‌های موکداً تعریف شده ارتباط برقرار می‌کنند؛ بنابراین، فقط زیرسامانه تأثیر پذیرفته، برای بازیابی حالت مجاز، باید راه‌اندازی مجدد گردد. این موضوع برای زیر سامانه‌های موجود در فرایند مشابه درست نیست، چراکه در آن یک اشاره‌گر سرکش در یک زیرسیستم به صورت تصادفی، می‌تواند دیگر زیرسامانه‌ها را خراب کند.
برنامه‌نویسان COM نرم‌افزارشان را به کمک مولفه‌های مطلع از COM می‌سازند. انواع مختلف مولفه توسط ID کلاس شناسایی می‌شوند (CLSIDs) که شناسانه‌های یکتای جهانی هستند (GUIDs). هر مولفه COM، کارایی اش را از طریق یک یا بیشتر واسط در معرض دید قرار می‌دهد. واسط‌های مختلفی که توسط یک مولفه پشتیبانی می‌شوند، توسط ID واسط شان (IID) از یکدیگر مجزا می‌گردند، که این IIDها GUID هم هستند. واسط‌های COM بستگی‌هایی در زبان‌های مختلف مثل C, C++، ویژوال بیسیک، دلفی، پایتون، و دیگر زبان‌های اجرانامه‌نویسی که در بن‌سازه ویندوز پیاده‌سازی شده‌اند دارند. تمام دسترسی‌ها به مولفه‌ها از طریق شگردهای واسط‌ها انجام می‌شود. این موضوع امکان فن‌آوری‌هایی مثل برنامه‌نویسی بین‌پردازه‌ای یا حتی برنامه‌نویسی بین‌رایانه‌ای را فراهم می‌کند (که دومی از طریق پشتیبانی از DCOM انجام می‌شود).
همه مولفه‌های COM واسط (سفارشی) IUnknown را پیاده‌سازی می‌کنند، که شگردهایی برای شمارش ارجاع و تبدیل نوع (ریخته‌گری نوع) نمایان می‌سازند. یک واسط سفارشی IUnknown شامل یک اشاره‌گر به جدول شگرد مجازی است، که شامل یک لیست از اشاره‌گرها به توابعی است که توابع اعلان شده در واسط را پیاده‌سازی می‌کنند، و این موضوع به همان ترتیبی انجام می‌شود که در واسط اعلان شده‌اند. از این رو سربار فراخوانی بین‌پردازشی قابل مقایسه با تماس‌های شگرد مجازی در C++ است. علاوه بر واسط‌های سفارشی، COM از واسط‌های اعزامی نیز پشتبانی می‌کند، که از IDispatch ارث‌بری می‌کنند. واسط‌های اعزامی از «بستگی دیرموقع» برای خودکارسازی OLE پشتیبانی می‌کنند. این موضوع به واسط‌های اعزامی امکان می‌دهد تا به صورت محلی توسط محدوده گسترده‌تری از زبان‌های برنامه‌نویسی نسبت به واسط‌های سفارشی دسترسی بیابند.
یک کلاس COM یا «coclass» یک پیاده‌سازی عینی از یک یا بیشتر واسط است، و خیلی به کلاس‌های موجود در زبان‌های برنامه‌نویسی شیءگرا شبیه است. این کلاس‌ها بر اساس ID کلاس‌شان (CLSID)، یا براساس رشته شناسه برنامه‌نویسی‌شان (ProgID) ساخته می‌شوند. مثل خیلی از زبان‌های شیءگرا، COM قابلیت جداسازی واسط از پیاده‌سازی را فراهم می‌بیند. این تفکیک مخصوصاً در COM زیاد است، زیرا در آن اشیا را نمی‌توان به صورت مستقیم به اشیا دسترسی یافت، بلکه فقط از طریق واسط شان قابل دسترسی هستند. COM از موضوع چندین پیاده‌سازی برای یک واسط پشتیبانی می‌کند، که در نتیجه آن کارخواه‌ها در زمان اجرا می‌توانند انتخاب کنند که کدام پیاده‌سازی از یک واسط را نمونه برداری کنند.
کتابخانه‌های نوع شامل فراداده‌هایی هستند که می‌توانند انواع COM را نمایش دهند. این نوع‌ها توسط زبان تعریف واسط مایکروسافت (MSIDL/IDL) توصیف شده‌اند. فایل‌های IDL تعریف کننده کلاس‌ها، واسط‌ها، ساختارها، فهرست‌شمارای شیءگرا، و دیگر انواع تعریف شده توسط کاربر هستند و این تعریف‌ها به حالت مستقل از زبان هستند. IDL از نظر ظاهری مشابه اعلان‌های C++ است، اما در آن کلیدواژه‌های اضافی مثل «interface", "library»، برای تعریف واسط‌ها و گردآوردهای کلاس‌ها وجود دارد. IDL از ویژگی‌های قلابی، قبل از اعلان‌ها پشتیبانی می‌کند، تا اطلاعات اضافی را تهیه ببیند مثلاً GUIDهای واسط، و رابطه بین پارامترهای اشاره‌گر و فیلدهای طول. فایل‌های IDL توسط کامپایلر MIDL کامپایل می‌شوند. برای C/C++، کامپایلر MIDL بک فایل سرایند مستقل از کامپایلر تولید می‌کند، که شامل تعاریف سختارها است تا vtblهای واسط‌های اعلان‌شده و یک فایل C شامل اعلان‌های GUIDهای واسط را منطبق کند. کد منبع C++ برای یک پودمان پراکسی را نیز می‌توان توسط کامپایلر MIDL تولید کرد. این پراکسی شامل سه‌رسید شگرد برای تبدیل تماس COM به تماس‌های رویه دوردست است تا به DCOM امکان ارتباطات بیرون‌ازفرایند را بدهد. فایل‌های IDL را توسط کامپایلر MIDL می‌توان به یک کتابخانه نوع (TLB) کامپایل کرد. فایل‌های TLB شامل فراداده‌های دودویی است که قابلیت پردازش توسط کامپایلرهای زبانی مختلف و محیط‌های زمان‌اجرای مختلف (مثل VB، دلفی، دات‌نت، و غیره) را دارد، و در نتیجه ساختارهای خاص‌زبانه‌ای تولید می‌شود که نمایش‌دهنده انواع COM تعریف شده در TLB هستند. برای C++، این موضوع TLB را به نمایش IDL آن برمی‌گرداند.
به دلیل آنکه COM یک چارچوب زمان‌اجرا است، انواع را باید به صورت منفرد در زمان‌اجرا تشخیص داد و تعیین کرد. برای این موضوع از شناسه‌های یکتای جهانی (GUIDها) استفاده می‌شود. هر نوع COM یک GUID طراحی شده خاص خودش برای شناسایی در زمان اجرا دارد. برای آنکه اطلاعات انواع COM هم در زمان‌اجرا و هم‌زمان کامپایل دردسترس باشند، COM از کتابخانه‌های نوع استفاده می‌کند. این موضوع از طریق استفاده مؤثر از «کتابخانه‌های نوع» به دست می‌آید، که COM از طریق یک چارچوب پویا برای تعامل با اشیا به توانمندی‌اش می‌رسد.
این مثال تعریف coclass در یک IDL را درنظر بگیرید: coclass SomeClass { در قطعه کد بالا یک کلاس COM اعلان شده‌است، که SomeClass نام‌دارد، که یک واسط با نام ISomeInterface را پیاده‌سازی می‌کند.
این از نظز معنایی معادل تعریف کلاس C++ زیر است: class SomeClass : public ISomeInterface { در اینجا ISomeInterface یک کلاس کاملاً مجازی C++ است (که گاهی به آن کلاس مبنای انتزاعی گفته می‌شود).
فایل‌های IDL شامل واسط‌ها و کلاس‌های COM به فایل‌های کتابخانه نوع (TLB) کامپایل می‌شوند، که بعداً در زمان‌اجرا توسط کارخواه‌ها قابل تجزیه اند، تا تعیین کنند که کدام یک پشتیبانی شیء را واسط سازی می‌کنند، و شگردهای واسط شیء را فراخوانی می‌کنند.
در C++، اشیای COM توسط تابع codice_1 نمونه‌برداری می‌شوند، که ID کلاس (CLSID) و ID واسط (IID) را به عنوان آرگومان می‌گیرد. نمونه‌برداری از SomeClass را به اینگونه می‌توان پیاده‌سازی کرد: ISomeInterface* interface_ptr = NULL; HRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL, در این مثال، زیرسامانه COM برای به دست آوردن یک اشاره‌گر به شیء ای که واسط codice_2 راپیاده‌سازی می‌کند، استفاده می‌شود، و پیاده‌سازی خاص coclass با نام CLSID_SomeClass از این واسط مورد نیاز است.
همه اشیای COM از شمارش ارجاع برای مدیریت زمان‌زندگی اشیاء استفاده می‌کنند. تعداد ارجاع‌ها توسط کارخواه‌ها از طریق شگردهای "AddRef" و "Release" در واسط اجباری IUnknown کنترل می‌شوند، که این واسط را همه اشیای COM پیاده‌سازی کرده‌اند. اشیای COM آنوقت مسئول خالی‌سازی حافظه خودشان اند و این موضوع وقتی رخ می‌دهد که تعداد ارجاع‌ها به صفر کاهش می‌یابد. زبان‌های خاص (مثل ویژوال بیسیک) امکان شمارش خودکار ارجاع را فراهم می‌کنند، که در نتیجه آن توسعه‌دهندگان اشیای COM نیازی به نگهداری صریح هیچ شمارشگر ارجاع درونی در کد منبع‌شان را ندارند. در C++، یک کدنویس برای مدیریت تعداد ارجاع‌ها، یا از انجام شمارش صریح ارجاع استفاده می‌کند، یا از اشاره‌گرهای هوشمند استفاده می‌کند، تا به صورت خودکار مدیریت تعداد ارجاع انجام شود.
در زیر راهبردهایی برای زمان استفاده فراخوانی "AddRef" و "Release" روی اشیای COM آمده‌است:
همه تعداد ارجاع‌ها به اشیای دوردست روی یک خط ارسال نمی‌شوند؛ بلکه یک پراکسی فقط یک ارجاع را روی شیء دوردست نگه‌می‌دارد و تعداد ارجاع محلی خودش را نگهداری می‌کند. برای ساده‌سازی توسعه COM، مایکروسافت ATL را برای توسعه‌دهندگان C++ معرفی کرده‌است که کوته‌نوشت «کتابخانه الگوی فعال Active Template Library» است. ATL یک فراالگوی توسعه COM سطح بالاتر را فراهم می‌بیند. این موضوع توسعه‌دهندگان کاربردی کارخواه COM را از نیاز برای نگهداری مستقیم تعداد ارجاع محافظت می‌کند، این کار از طریق تهیه اشیای اشاره‌گر هوشمند انجام می‌شود. دیگر کتابخانه‌ها و زبان‌های مطلع از COM شامل کتابخانه کلاس‌های بنیاد مایکروسافت، پشتیبانی COM در کامپایلر VC, و VBScript، و ویژوال بیسیک؛ و اکمااسکریپت (جاوااسکریپت) و برلند دلفی می‌شوند.
COM یک استاندارد دودویی منکر زبان است، که می‌توان آن را در هر زبان برنامه‌نویسی که قادر به فهم و پیاده‌سازی انواع داده و واسط‌های دودویی تعریف شده اش هستند، توسعه داد. پیاده‌سازی‌های COM مسئول ورود و خروج از محیط COM، نمونه‌برداری و شمارش-ارجاع اشیای COM، پزسمان از اشیا برای واسط‌های پشتیبانی شده، و نیز رسیدگی به حالت استثنا هستند. کامپایلر C++ دیداری مایکروسافت، از افزونه‌های زبان C++ که به آن "C++ Attributes" گفته می‌شود، پشتیبانی می‌کنند. این افزونه‌ها برای ساده‌سازی توسعه COM و حذف بسیاری از کدهای لوله‌کشی مورد نیاز برای پیاده‌سازی سرور COM در C++ طراحی شده‌اند.
در ویندوز، کلاس‌های COM، واسط‌ها، و کتابخانه‌های نوع، توسط GUIDها در رجیستری فهرست شده‌اند، و برای کلاس‌ها تحت "HKEY_CLASSES_ROOT\CLSID" و برای واسط‌ها تحت "HKEY_CLASSES_ROOT\Interface" قرار دارند. کتابخانه‌های COM از رجیستری برای تعیین محل یا کتابخانه‌های محلی صحیح برای هر شیء COM یا محل شبکه‌ای برای یک خدمت دوردست استفاده می‌کنند.
COMهای بدون رجیستری (RegFree COM) یک فن‌آوری معرفی شده توسط ویندوز اکس‌پی است که به مولفه‌های مدل شیء مولفه (COM) امکان ذخیره فراداده فعال‌سازی و CLSID (یا Class ID) را برای مولفه‌ها بدون استفاده از رجیستری می‌دهد. در عوض، فراداده و CLSIDهای کلاس‌های پیاده‌سازی شده در مولفه در صورت‌کد اسمبلی اعلان می‌شوند (به کمک XML توصیف می‌شوند) یا به صورت یک منبع در اجراپذیر ذخیره می‌شوند، یا به صورت یک فایل مجزا همراه مولفه نصب می‌گردند. این موضوع امکان آن را فراهم می‌کند تا نسخه‌های مختلفی از یک مولفه مشابه در دایرکتوری‌های مختلف نصب گردند، و توسط صورت‌کدهای خاص خودشان توصیف شوند، مثلاً در استقرار XCOPY این موضوع وجود دارد. این فن‌آوری پشتیبانی کمی در سرورهای EXE COM دارد و در مولفه‌های سطح سیستم، مثل MDAC, MSXML, DirctX یا اینترنت اکسپلورر قابل استفاده نیستند.
در مدت بارگذاری برنامه‌کاربردی، بارگذار ویندوز دنبال صورت‌کد می‌گردد. اگر موجود باشد، بارگذار، اطلاعات آن را به بافت فعال‌سازی اضافه می‌کند. موقعی که کارخانه کلاس COM بخواهد یک کلاس را نمونه‌برداری کند، بافت فعال‌سازی اول بررسی می‌شود تا ببیند آیا یک پیاده‌سازی از CLSID را می‌توان یافت یا نه. فقط موقعی که نتیجه جستجو منفی باشد، رجیستری بررسی می‌شود.
اشیای COM را به صورت دستی هم می‌توان ساخت. در این موقع باید مسیر فایل DLL، و GUID شیء را داشته باشیم. این موضوع نیازی به بایگانی DLL یا GUID در رجیستری سامانه ندارد، و از فایل‌های صورت‌کد هم استفاده نمی‌کند. یک DLL یک تابع به نام DllGetClassObject را صادر می‌کند. صدازدن DllGetClassObject با GUIDها و IID_IClassFactory مورد نیاز، یک نمونه از یک شیء کارخانه را تهیه می‌بیند. شیء کتابخانه یک شگرد CreateInstance دارد، که می‌تواند نمونه‌های یک شیء را اگر یک GUID واسط به آن بدهیم، بسازد. این فرایند مشابهی است که موقعی که به صورت درونی نمونه‌های مولفه‌های COM رجیستر شده را می‌سازیم، استفاده می‌شود.
اگر شیء COM ساخته شده، از شیء COM دیگری به کمک CoCreateInstance API همگانی نمونه‌برداری کند، این کار را از طریق روش عمومی معمول انجام می‌دهد، یعنی از رجیستری یا فایل‌های صورت‌کد استفاده می‌کند. اما می‌تواند اشیای درونی را بسازد (که ممکن است اصلاً رجیستر نشود)، و ارجاع‌ها به واسط‌های آن را به دست چیز بیرونی بدهد، و این کار را به کمک دانش خصوصی خودش انجام دهد.
اشیای COM را می‌توان در داخل پردازه مشابه (in-process) یا در مرزهای بین پردازه‌ای (out-of-process)، یا از راه‌دور روی شبکه (DCOM) به صورت شفاف نمونه‌برداری کرد و ارجاع داد. اشیای برون‌پردازه‌ای یا راه‌دور از صف‌آرایی برای پیاپی‌سازی تماس‌های شگردی، و مقادیر بازگشتی روی مرزهای پردازه، یا شبکه استفاده می‌کنند. این صف‌آرایی برای کارخواه قابل دیدن نیست، زیرا او به شیء به این صورت دسترسی دارد که مثل آن است که این یک شیء محلی درون پردازه‌ای است.
در COM، ریسه‌دهی توسط مفهومی به نام آپارتمان ("apartments") تعیین می‌شود. یک شیء COM منفرد دقیقاً در یک آپارتمان زندگی می‌کند، که این آپارتمان می‌تواند یا یک-ریسه‌ای یا چند-ریسه‌ای باشد. سه نوع آپارتمان در COM وجود دارد: آپارتمان تک-ریسه‌ای (STA)، آپارتمان چند-ریسه‌ای (MTA) و آپارتمان خنتثی از نظر ریسه. هر آپارتمان نمایش‌دهنده یک سازکار است که به کمک آن حالت درونی شیء را می‌توان بین چندین ریسه همزمان‌سازی کرد. یک پردازه می‌تواند شامل چندین شیء COM باشد، که بعضی از آن‌ها از STA استفاده می‌کنند، بقیه می‌توانند از MTA استفاده کنند. همهٔ ریسه‌هایی که به اشیای COM دسترسی می‌یابند، به صورت مشابه در یک آپارتمان زندگی می‌کنند. انتخاب نوع آپارتمان برای اشیای COM و ریسه‌ها در زمان‌اجرا تعیین می‌شود، و این موضوع قابل تغییر نیست.
اشیا و ریسه‌هایی که به یک آپارتمان تعلق دارند، از قواعد دسترسی به ریسه مشابهی پیروی می‌کنند. فراخوانی شگردی که در داخل آپارتمان مشابهی انجام می‌شوند، به صورت مستقیم انجام می‌شوند، یعنی هیچ کمکی از جانب COM نمی‌گیرند. فراخوانی شگرد که بین آپارتمان‌ها انجام می‌شوند، از طریق صف‌آرایی به دست می‌آیند. این موضوع نیاز به استفاده از پراکسی و ته‌رسید دارد.
به دلیل آنکه COM پیاده‌سازی واقعاً پیچیده‌ای دارد، ممکن است برنامه‌نویسان توسط بعضی از مسائل «لوله‌کشی» پریشان شوند.
موقعی که یک STA نمونه‌برداری می‌شود، یک پنجرهٔ پنهان را می‌سازد که از آن برای راه‌یابی برای پیام‌های داخل آپارتمانی یا داخل پردازه‌ای استفاده می‌شود. در این پنجره، باید صف پیامی‌اش به صورت مرتب «پمپ» شود. به این ساختار «پمپ پیامی» می‌گویند. در ورژن‌های قدیمی ویندوز، ناتوانی در انجام این کار می‌توانست منجر به بن‌بست‌های سطح سامانه شود. این موضوع توسط بعضی از APIهای ویندوز که COM را به عنوان بخشی از پیاده‌سازی شان راه‌اندازی می‌کردند، پیچیده‌تر می‌شد، و این کار باعث «نشت» جزییات پیاده‌سازی می‌شود.
اگر دو یا بیشتر شیء به صورت چرخه‌ای ارجاع‌دهی شوند، شمارش ارجاع در داخل COM می‌تواند منجر به مشکل‌هایی شود. طراحی برنامه‌کاربردی باید این موضوع را درنظر بگیرد، و درنتیجه آن اشیا نباید یتیم باقی بمانند. اگر مدل «غرق وقعه» COM استفاده شود، اشیا ممکن است با وجود تعداد ارجاع فعال از بین بروند. به دلیل آنکه شیءای که وقعه را بیرون داده‌است، نیاز به یک ارجاع به شیءای دارد که به وقعه واکنش نشان می‌دهد، تعداد ارجاع دومی هیچگاه به صفر نمی‌رسد. ارجاع‌های دایره‌وار معمولاً یا توسط فن «خاتمهٔ خارج از باند»، یا توسط فن «هویت جداکننده» شکسته می‌شوند. در تکنیک خاتمه خارج از باند، یک شیء یک شگرد را نمایان می‌سازد که موقعی که صدازده شود، آن شیء را مجبور می‌سازد که ارجاع‌هایش به دیگر اشیاء را از بین ببرد، و از این رو چرخه را بشکند. در فن هویت جداکننده، یک پیاده‌سازی منفرد، دو شیء COM را نمایان می‌سازد (که به آن هویت گفته می‌شود). این موضوع باعث ایجاد یک ارجاع ضعیف، بین اشیای COM می‌شود، و از یک چرخه ارجاع جلوگیری می‌کند.
به دلیل آنکه مولفه‌های COM درون-پردازه‌ای در فایل‌های DLL پیاده‌سازی می‌شوند، و رجیسترکردن تنها به یک ورژن منفرد برای هر CLSID امکان حضور می‌دهد، آن‌ها ممکن است در بعضی حالات در معرض اثر «جهنم DLL» قرار گیرند. توانمندی COMهای بدون رجیستری این مسئله را برای مولفه‌های درون-پردازه‌ای حذف می‌کند؛ اما توانمندی COM بدون رجیستری برای سرورهای برون-پردازه‌ای در دسترس نیستند.