نموذج كائن المكون  نموذج كائن المكون (حاسوب)و اختصارا ب (COM) وبالانجليزية (Component Object Model) هو معيار واجهة ثنائية لمكونات البرامج التي قدمتها Microsoft في 1993. يتم استخدامه لتمكين إنشاء كائن الاتصال بين العمليات في مجموعة كبيرة من لغات البرمجة. يعد COM أساسًا للعديد من تقنيات وأطر عمل Microsoft الأخرى، بما في ذلك OLE و OLE Automation و Browser Helper Object وActiveX و COM + و DCOM وWindows shell وDirectX و UMDF و Windows Runtime . جوهر COM هو طريقة لغة محايدة لتنفيذ الأشياء التي يمكن استخدامها في بيئات مختلفة عن تلك التي تم إنشاؤها فيها، حتى عبر حدود الماكينة. بالنسبة للمكونات المصممة جيدًا، يسمح COM بإعادة استخدام الكائنات بدون معرفة بتنفيذها الداخلي، حيث يفرض على منفذي المكونات توفير واجهات محددة جيدًا منفصلة عن التنفيذ. يتم استيعاب دلالات التخصيص المختلفة للغات من خلال جعل الكائنات مسؤولة عن إنشائها وتدميرها من خلال العد المرجعي. يتم تحقيق تحويل النوع بين واجهات مختلفة لكائن من خلال أسلوب codice_1 الأسلوب المفضل لـ «الوراثة» داخل COM هو إنشاء كائنات فرعية يتم تفويض «استدعاءات» الأسلوب إليها.  COM هي تقنية واجهة تم تعريفها وتنفيذها كمعيار فقط على مايكرو سوفت وندوز و Apple's Core Foundation 1.3 وما بعده من واجهة برمجة التطبيقات الإضافية (API). يقوم الأخير فقط بتنفيذ مجموعة فرعية من واجهة COM بأكملها. بالنسبة لبعض التطبيقات، تم استبدال COM على الأقل إلى حد ما بواسطة Microsoft. NET Framework ودعم خدمات الويب من خلال Windows Communication Foundation (WCF). (اساسيات اتصال وندوز ))ومع ذلك، يمكن استخدام كائنات COM مع الكل. NET من خلال. NET COM Interop . يستخدم Networked DCOM تنسيقات الملكية الثنائية، بينما يشجع WCF على استخدام رسائل SOAP المستندة إلى XML. يشبه COM إلى حد كبير تقنيات واجهة برمجيات المكونات الأخرى ، مثل CORBA وEnterprise JavaBeans ، على الرغم من أن لكل منهما نقاط قوة وضعف خاصة به. على عكس ++C ، يوفر COM واجهة تطبيق ثنائية ثابتة (ABI) لا تتغير بين إصدارات المحول البرمجي. هذا يجعل واجهات COM جذابة لمكتبات ++C الموجهة للكائنات والتي سيتم استخدامها من قبل العملاء الذين تم تجميعهم باستخدام إصدارات مترجم مختلفة.  كانت إحدى الطرق الأولى للاتصال بين العمليات في وندوز هي تبادل البيانات الديناميكي (DDE)، تقديمه لأول مرة في عام 1987، والذي سمح بإرسال واستقبال الرسائل فيما يسمى بـ «المحادثات» بين التطبيقات. قام أنتوني ويليامز، الذي شارك في إنشاء بنية COM ، في وقت لاحق بتوزيع ورقتين داخليتين في ميكروسوفت احتضنتا مفهوم مكونات البرامج: "هندسة الكائنات: التعامل مع أمان النوع غير المعروف أو النوع في مكتبة فئة قابلة للتوسيع ديناميكيًا" في عام 1988 و "عن الميراث: ما يعنيه وكيفية استخدامه" عام 1990. قدمت هذه الأساس للعديد من الأفكار وراء COM. تم إنشاء ارتباط الكائنات وتضمينها (OLE)، وهو أول إطار عمل يستند إلى الكائنات من ميكروسوفت، فوق DDE وتم تصميمه خصيصًا للمستندات المركبة. تم تقديمه مع Word for Windows ومايكروسوفت اكسل في عام 1991، وتم تضمينه لاحقًا مع وندوز، بدءًا من الإصدار 3.1 في عام 1992. مثال على المستند المركب هو جدول بيانات مضمن في مستند وورد لـ وندوز: عندما يتم إجراء تغييرات على جدول البيانات داخل اكسل، فإنها تظهر تلقائيًا داخل مستند وورد.  في عام 1991، قدمت ميكروسوفت ملحقات فيجوال بيسك (VBX) مع Visual Basic 1.0. VBX هو امتداد حزم في شكل مكتبة ارتباط ديناميكي (DLL) يسمح بوضع الكائنات بيانياً في نموذج ومعالجتها بواسطة الخصائص والطرق. تم تكييفها لاحقًا للاستخدام من قبل لغات أخرى مثل Visual C ++ . في عام 1992 ، عندما تم إطلاق الإصدار 3.1 من Windows ، أصدرت Microsoft OLE 2 مع نموذج الكائن الأساسي الخاص بها. كانت الواجهة الثنائية لتطبيق COM (ABI) هي نفسها واجهة MAPI ABI (التي تم إصدارها في عام 1992)، ومثلها كانت تستند إلى MSRPC وفي النهاية على DCE / RPC للمجموعة المفتوحة. بينما ركز OLE 1 على المستندات المركبة، تم تصميم COM و OLE 2 لمعالجة مكونات البرامج بشكل عام. أثبتت المحادثات النصية ورسائل مايكروسوفت ويندوز أنها ليست مرنة بما يكفي للسماح بمشاركة ميزات التطبيق بطريقة قوية وقابلة للتوسيع، لذلك تم إنشاء COM كأساس جديد، وتغير OLE إلى OLE2. في عام 1994، تم تقديم عناصر تحكم OLE المخصصة (OCXs) كخلف لعناصر تحكم VBX. في الوقت نفسه، صرحت مايكروسوفت أن OLE 2 سيعرف فقط باسم "OLE"، وأن OLE لم يعد اختصارًا، ولكنه اسم لجميع تقنيات مكونات الشركة. في أوائل عام 1996، اكتشفت مايكروسوفت استخدامًا جديدًا لعناصر تحكم OLE المخصصة، مما أدى إلى توسيع قدرة مستعرض الويب الخاص بهم على تقديم المحتوى، وإعادة تسمية بعض أجزاء OLE المتعلقة بالإنترنت «ActiveX»، وإعادة تسمية جميع تقنيات OLE تدريجياً إلى ActiveX ، باستثناء تقنية المستندات المركبة التي تم استخدامها في Microsoft Office . في وقت لاحق من ذلك العام، قامت Microsoft بتمديد COM للعمل عبر الشبكة مع DCOM.  كان COM هو المنصة الرئيسية لتطوير البرامج لنظام وندوز، وبالتالي أثر في تطوير عدد من التقنيات الداعمة. وبالمثل تأثرت بشدة بالتقنيات السابقة.  استبدل COM DDE باعتباره الشكل المفضل للاتصال بين العمليات.  كنموذج مكون متعدد اللغات، يعتمد COM على لغة تعريف الواجهة، أو IDL ، لوصف الكائنات والوظائف المرتبطة بها. يعتمد COM IDL بشكل كبير على DCE / RPC IDL الغني بالميزات، مع امتدادات موجهة للكائنات. يتم استخدام تطبيق مايكروسوفت الخاص لـ DCE / RPC ، والمعروف باسم MSRPC ، بشكل كبير كآلية اتصال أساسية بين العمليات لخدمات Windows NT والمكونات الداخلية، مما يجعلها اختيارًا واضحًا للمؤسسة.  قام DCOM ("الموزع COM") بتوسيع نطاق وصول COM من مجرد دعم مستخدم واحد بتطبيقات منفصلة متصلة على سطح مكتب وندوز، إلى تنشيط الكائنات التي تعمل في ظل سياقات أمان مختلفة، وعلى أجهزة مختلفة عبر الشبكة. مع هذا تمت إضافة الميزات الضرورية لتكوين المستخدمين الذين لديهم سلطة إنشاء الكائنات وتفعيلها واستدعاءها، لتحديد المستخدم المتصل، بالإضافة إلى تحديد التشفير المطلوب لتأمين المكالمات.  لكي تقدم Microsoft للمطورين دعمًا للمعاملات الموزعة، وتجميع الموارد، والتطبيقات غير المتصلة، ونشر الأحداث والاشتراك فيها، وإدارة أفضل للذاكرة والمعالج (الخيط)، بالإضافة إلى وضع Windows كبديل لأنظمة التشغيل الأخرى على مستوى المؤسسة، قدمت Microsoft تقنية تسمى Microsoft Transaction Server (MTS) على Windows NT 4. مع Windows 2000، تم دمج هذا الامتداد الهام لـ COM في نظام التشغيل (على عكس سلسلة الأدوات الخارجية التي توفرها MTS) وأعيدت تسميته COM + . في الوقت نفسه، تخلصت Microsoft من التركيز على DCOM ككيان منفصل. المكونات التي تستخدم خدمات COM + تمت معالجتها بشكل مباشر أكثر من خلال الطبقة المضافة من COM + ، لا سيما من خلال دعم نظام التشغيل للاعتراض. في الإصدار الأول من MTS ، تم الاعتراض على - تثبيت مكون MTS من شأنه تعديل سجل Windows لاستدعاء برنامج MTS ، وليس المكون مباشرة. قام Windows 2000 أيضًا بمراجعة تطبيق لوحة تحكم خدمات المكونات المستخدم لتكوين مكونات COM +.  تتمثل إحدى ميزات COM + في أنه يمكن تشغيله في «مزارع المكونات». يمكن تجميع مثيلات المكون، إذا تم ترميزها بشكل صحيح، وإعادة استخدامها بواسطة استدعاءات جديدة إلى روتين التهيئة الخاص بها دون تفريغها من الذاكرة. يمكن أيضًا توزيع المكونات (يتم استدعاؤها من جهاز آخر). قدم COM + وMicrosoft Visual Studio أدوات لتسهيل إنشاء وكلاء من جانب العميل، لذلك على الرغم من استخدام DCOM لإجراء مكالمة عن بُعد، كان من السهل القيام به للمطورين. قدم COM + أيضًا آلية حدث مشترك / ناشر تسمى أحداث COM + ، وقدمت طريقة جديدة للاستفادة من MSMQ (وهي تقنية توفر رسائل غير متزامنة بين التطبيقات) مع مكونات تسمى «المكونات المدرجة في قائمة الانتظار» . تعمل أحداث COM + على توسيع نموذج برمجة COM + لدعم الأحداث ذات الصلة المتأخرة (انظر الربط المتأخر) أو استدعاءات الأسلوب بين الناشر أو المشترك ونظام الأحداث.  مايكروسوفت. يوفر (NET) وسائل لتوفير تقنية المكونات والتفاعل مع COM + (عبر تجميعات COM-interop)؛ . يوفر NET أغلفة لمعظم عناصر تحكم COM الشائعة الاستخدام. مايكروسوفت. تخفي NET معظم التفاصيل من إنشاء المكونات وبالتالي تسهل التطوير. . يمكن لـ NET الاستفادة من COM + عبر النظام. تم تكرار مساحة اسم Enterprise Services والعديد من الخدمات التي يوفرها COM + في الإصدارات الأخيرة من. صافي. على سبيل المثال، النظام. مساحة اسم المعاملات بتنسيق. توفر NET فئة TransactionScope ، والتي توفر إدارة المعاملات دون اللجوء إلى COM +. وبالمثل، يمكن استبدال المكونات الموجودة في قائمة الانتظار بواسطة Windows Communication Foundation(اساسيات اتصال وندوز) بنقل MSMQ. (MSMQ هو مكون COM أصلي، ومع ذلك.) يوجد دعم محدود للتوافق مع الإصدارات السابقة. يمكن استخدام كائن COM في. NET عن طريق تنفيذ Runtime Callable Wrapper (RCW). يمكن استخدام كائنات NET التي تتوافق مع قيود واجهة معينة في كائنات COM عن طريق "استدعاء مجمّع COM القابل للاستدعاء" (CCW). من كل من COM و. جوانب NET ، تظهر الكائنات التي تستخدم التكنولوجيا الأخرى ككائنات أصلية. انظر COM Interop . WCF (Windows Communication Foundation)) يخفف عددًا من تحديات التنفيذ عن بُعد الخاصة بـ COM. على سبيل المثال، يتيح تنظيم الكائنات بشفافية حسب القيمة عبر حدود العملية أو الجهاز بسهولة أكبر.  إن برمجة وتطبيقات Microsoft Windows Runtime (أو WinRT ، التي لا ينبغي الخلط بينها وبين Windows RT) هي في الأساس واجهة برمجة تطبيقات تستند إلى COM ، على الرغم من أنها تعتمد على COM محسّن. نظرًا لأساسه الشبيه بـ COM ، يسمح Windows Runtime بالتفاعل السهل نسبيًا من لغات متعددة، تمامًا كما يفعل COM ، ولكنه في الأساس واجهة برمجة تطبيقات أصلية غير مُدارة. ومع ذلك، يتم تخزين تعريفات واجهة برمجة التطبيقات في ملفات ".winmd"، والتي تم ترميزها بتنسيق البيانات الوصفية ECMA 335، وهو نفس تنسيق بيانات CLI الوصفية. يستخدم NET مع بعض التعديلات. يسمح تنسيق البيانات الوصفية الشائع هذا بتكاليف أقل بكثير من P / Invoke عند استدعاء WinRT من. NET ، وصياغتها أبسط بكثير.  Nano-COM عبارة عن مجموعة فرعية صغيرة جدًا من نموذج كائن المكون الذي يركز حصريًا على جوانب واجهة التطبيق الثنائية (ABI) في COM لتمكين استدعاءات الوظيفة والطريقة عبر الوحدات / المكونات المجمعة بشكل مستقل. يمكن التعبير عن Nano-COM بسهولة في ملف رأس C ++ واحد قابل للنقل لجميع برامج التحويل البرمجي لـ C ++. يقوم Nano-COM بتوسيع ABI الأصلي لهندسة التعليمات الأساسية ونظام التشغيل لإضافة دعم لمراجع الكائنات المكتوبة (تركز ABI النموذجي فقط على الأنواع الذرية والهياكل والمصفوفات واصطلاحات استدعاء الوظائف). تم استخدام أساس Nano-COM بواسطة Mozilla لتشغيل Firefox (يسمى XPCOM)، وهو قيد الاستخدام حاليًا كتقنية ABI الأساسية لـ DirectX / Direct3D / DirectML.  يحدد ملف رأس Nano-COM أو يسمي ثلاثة أنواع على الأقل:   تحدد العديد من استخدامات Nano-COM أيضًا وظيفتين لمعالجة مخازن الذاكرة المخصصة للمستدعي كنتائج   بعض تطبيقات Nano-COM مثل Direct3D تتجنب وظائف المخصص وتقييد نفسها لاستخدام المخازن المؤقتة المخصصة للمتصل فقط.  لا يوجد لدى Nano-COM فكرة عن الفئات والشقق والتنظيم والتسجيل وما إلى ذلك. بدلاً من ذلك، يتم تمرير مراجع الكائنات ببساطة عبر حدود الوظيفة وتخصيصها عبر تركيبات اللغة القياسية (على سبيل المثال، عامل تشغيل جديد C ++).  يتم تشغيل مكونات COM و ActiveX كرمز أصلي على جهاز المستخدم، بدون وضع الحماية. لذلك، هناك قيود قليلة على ما يمكن أن يفعله الكود. وبالتالي، أدت الممارسة السابقة المتمثلة في تضمين مكونات ActiveX على صفحات الويب باستخدام Internet Explorer إلى حدوث مشكلات مع الإصابات بالبرامج الضارة. تعرفت Microsoft على مشكلة ActiveX منذ عام 1996 عندما قال Charles Fitzgerald ، «لم نطلق أبدًا الادعاء مقدمًا بأن ActiveX آمن جوهريًا». حديث  إصدارات Internet Explorer تطالب المستخدم قبل تثبيت عناصر تحكم ActiveX ، مما يتيح للمستخدم عدم السماح بتثبيت عناصر التحكم من المواقع التي لا يثق بها المستخدم. يتم توقيع عناصر تحكم ActiveX بالتوقيعات الرقمية لضمان صحتها. من الممكن أيضًا تعطيل عناصر تحكم ActiveX تمامًا، أو السماح لقلة محددة فقط. لا يزال الدعم الشفاف لخوادم COM خارج المعالجة يعزز أمان البرامج من حيث عزل العملية . يمكن أن يكون هذا مفيدًا لفصل الأنظمة الفرعية للتطبيق الكبير في عمليات منفصلة. يحد عزل العملية من فساد الدولة في عملية واحدة من التأثير سلبًا على نزاهة العمليات الأخرى، نظرًا لأنها تتواصل فقط من خلال واجهات محددة بدقة. وبالتالي، يحتاج النظام الفرعي المتأثر فقط إلى إعادة التشغيل لاستعادة الحالة الصالحة. ليس هذا هو الحال بالنسبة للأنظمة الفرعية في نفس العملية، حيث يمكن "لمؤشر مخادع" في نظام فرعي واحد أن يفسد الأنظمة الفرعية الأخرى بشكل عشوائي.  يقوم مبرمجو COM بإنشاء برامجهم باستخدام مكونات مدركة لـ COM. يتم تحديد أنواع المكونات المختلفة من خلال معرفات الفئة (CLSIDs)، وهي عبارة عن معرفات فريدة عالميًا (GUIDs). يعرض كل مكون COM وظائفه من خلال واجهة واحدة أو أكثر. يتم تمييز الواجهات المختلفة التي يدعمها أحد المكونات عن بعضها البعض باستخدام معرفات الواجهة (IIDs)، وهي عبارة عن معرفات GUID أيضًا. تحتوي واجهات COM على ارتباطات بعدة لغات، مثل C وC ++ و Visual Basic وDelphi وPython والعديد من لغات البرمجة النصية المطبقة على نظام Windows الأساسي. كل الوصول إلى المكونات يتم من خلال طرق الواجهات. يسمح هذا بتقنيات مثل العمليات البينية، أو حتى البرمجة بين الكمبيوتر (تستخدم الأخيرة دعم DCOM).  تقوم جميع مكونات COM بتنفيذ واجهة IUnknown ("المخصصة")، والتي تعرض طرقًا لحساب المراجع وتحويل النوع (الصب). تتكون واجهة IUnknown "المخصصة" من مؤشر لجدول أسلوب ظاهري يحتوي على قائمة بالمؤشرات إلى الوظائف التي تقوم بتنفيذ الوظائف المعلنة في الواجهة، بنفس الترتيب الذي تم الإعلان عنه في الواجهة. وبالتالي، فإن مقدار الحمل في العملية يمكن مقارنته باستدعاءات الطريقة الافتراضية في C ++ . بالإضافة إلى "الواجهات المخصصة" ، يدعم COM أيضًا "واجهات الإرسال" الموروثة من IDispatch . تدعم واجهات الإرسال الربط المتأخر لأتمتة OLE . يسمح ذلك بالوصول "إلى واجهات الإرسال" أصلاً من نطاق أوسع من لغات البرمجة مقارنة "بالواجهات المخصصة" .  فئة COM ("coclass") هي تطبيق ملموس لواجهة أو أكثر، وتشبه إلى حد كبير الفئات في لغات البرمجة الموجهة للكائنات. يتم إنشاء الفئات بناءً على معرف الفئة (CLSID) أو بناءً على سلسلة المعرف البرنامجي (ProgID). مثل العديد من اللغات الموجهة للكائنات، يوفر COM فصل الواجهة عن التنفيذ. هذا التمييز قوي بشكل خاص في COM ، حيث لا يمكن الوصول إلى الكائنات مباشرة، ولكن فقط من خلال واجهاتهم. يحتوي COM أيضًا على دعم للتطبيقات المتعددة للواجهة نفسها، بحيث يمكن للعملاء في وقت التشغيل اختيار أي تطبيق للواجهة يتم إنشاء مثيل له.  مكتبات النوع تحتوي على بيانات تعريف لتمثيل أنواع COM. يتم وصف هذه الأنواع باستخدام لغة تعريف واجهة Microsoft (MSIDL / IDL). تحدد ملفات IDL الفئات الموجهة للكائنات والواجهات والهياكل والتعدادات والأنواع الأخرى المعرفة من قبل المستخدم بطريقة مستقلة عن اللغة. يتشابه IDL في المظهر مع إعلانات C ++ مع بعض الكلمات الأساسية الإضافية مثل «واجهة» و «مكتبة» لتحديد الواجهات ومجموعات الفئات. يدعم IDL أيضًا استخدام السمات الموضوعة بين قوسين قبل الإعلانات لتوفير معلومات إضافية، مثل GUIDs للواجهة والعلاقات بين معلمات المؤشر وحقول الطول. يتم تصنيف ملفات IDL بواسطة مترجم MIDL. بالنسبة لـ C / C ++ ، ينشئ المحول البرمجي MIDL ملف رأس مستقل عن المترجم يحتوي على تعريفات بنية لمطابقة vtbls للواجهات المعلنة وملف C يحتوي على تعريفات للواجهة GUIDs . يمكن أيضًا إنشاء شفرة مصدر C ++ لوحدة وكيل بواسطة مترجم MIDL. يحتوي هذا الوكيل على كعب روتين أسلوب لتحويل مكالمات COM إلى استدعاءات الإجراءات البعيدة لتمكين DCOM للاتصالات خارج العملية. يمكن أيضًا تجميع ملفات IDL بواسطة مترجم MIDL في مكتبة النوع (TLB). تحتوي ملفات TLB على بيانات وصفية ثنائية يمكن معالجتها بواسطة مترجمي لغة مختلفين وبيئات وقت التشغيل (على سبيل المثال VB ، دلفي . NET وما إلى ذلك) لإنشاء بنيات خاصة باللغة لتمثيل أنواع COM المحددة في TLB. بالنسبة لـ C ++ ، سيؤدي ذلك إلى تحويل TLB مرة أخرى إلى تمثيل IDL الخاص به.  نظرًا لأن COM هو إطار عمل وقت التشغيل، يجب أن تكون الأنواع قابلة للتحديد والتحديد بشكل فردي في وقت التشغيل. لتحقيق ذلك، "يتم استخدام المعرفات الفريدة العالمية" (GUIDs). يتم تعيين كل نوع COM الخاص به GUID للتعريف في وقت التشغيل. من أجل الوصول إلى معلومات حول أنواع COM في كل من وقت الترجمة ووقت التشغيل، يستخدم COM مكتبات النوع. من خلال الاستخدام الفعال "لمكتبات النوع،" يحقق COM قدراته كإطار عمل ديناميكي للتفاعل بين الكائنات.  ضع في اعتبارك المثال التالي لتعريف coclass في IDL: coclass SomeClass { يعلن جزء التعليمات البرمجية أعلاه عن فئة COM تسمى codice_4 والتي تنفذ واجهة تسمى codice_5 .  هذا يعادل من الناحية المفاهيمية تحديد فئة C ++ التالية: class SomeClass : public ISomeInterface { حيث ISomeInterface هي فئة افتراضية خالصة C ++ (تسمى أحيانًا فئة أساسية مجردة).  يتم تجميع ملفات IDL التي تحتوي على واجهات وفئات COM في مكتبات النوع (TLB)، والتي يمكن تحليلها لاحقًا بواسطة العملاء في وقت التشغيل لتحديد الواجهات التي يدعمها الكائن، واستدعاء أساليب واجهة الكائن.  في C ++ ، يتم إنشاء كائنات COM باستخدام codice_6 التي تأخذ معرف الفئة (CLSID) ومعرف الواجهة (IID) كوسائط. يمكن تنفيذ مثيل codice_4 على النحو التالي: ISomeInterface* interface_ptr = NULL; HRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL, في هذا المثال، يتم استخدام النظام الفرعي COM للحصول على مؤشر لكائن يقوم بتنفيذ codice_5 ، ويلزم تطبيق coclass CLSID_SomeClass لهذه الواجهة.  تستخدم كافة كائنات COM حساب المرجع لإدارة عمر الكائن. يتم التحكم في عدد المراجع من قبل العملاء من خلال "أساليب AddRef" و "Release" في واجهة IUnknown الإلزامية التي تنفذها جميع كائنات COM. ثم تكون كائنات COM مسؤولة عن تحرير الذاكرة الخاصة بها عندما ينخفض عدد المراجع إلى الصفر. لغات معينة (مثل Visual Basic) يوفر حسابًا مرجعيًا تلقائيًا بحيث لا يحتاج مطورو كائن COM بشكل صريح إلى الاحتفاظ بأي عداد مرجعي داخلي في رموز المصدر الخاصة بهم. في C ++ ، قد يقوم المبرمج إما بإجراء حساب مرجعي صريح أو استخدام مؤشرات ذكية لإدارة أعداد المرجع تلقائيًا.  فيما يلي إرشادات حول وقت استدعاء "AddRef" و "Release" on COM:   لا يتم إرسال جميع مكالمات حساب المراجع إلى كائنات بعيدة عبر السلك؛ يحتفظ الوكيل بمرجع واحد فقط على الكائن البعيد ويحتفظ بعدد المرجع المحلي الخاص به. لتبسيط تطوير COM ، قدمت Microsoft ATL (Active Template Library) لمطوري C ++. يوفر ATL نموذج تطوير COM عالي المستوى. كما أنه يحمي مطوري تطبيقات عميل COM من الحاجة إلى الحفاظ على عد المرجع مباشرة، من خلال توفير كائنات مؤشر ذكية. تشمل المكتبات واللغات الأخرى المدركة لـ COM فئات Microsoft Foundation وVC Compiler COM Support و VBScript وVisual Basic وECMAScript (JavaScript) وBorland Delphi .  COM هو معيار ثنائي حيادي اللغة يمكن تطويره في أي لغة برمجة قادرة على فهم وتنفيذ أنواع البيانات والواجهات المعرفة الثنائية الخاصة بها. تعد تطبيقات COM مسؤولة عن الدخول إلى بيئة COM والخروج منها، وإنشاء كائنات COM وإحصاء المراجع، والاستعلام عن الكائنات للواجهات المدعومة، فضلاً عن معالجة الأخطاء. يدعم برنامج التحويل البرمجي Microsoft Visual C ++ ملحقات لغة C ++ المشار إليها باسم "سمات C ++". تم تصميم هذه الملحقات لتبسيط تطوير COM وإزالة الكثير من التعليمات البرمجية المعيارية المطلوبة لتنفيذ خوادم COM في C ++.  في Windows ، يتم سرد فئات COM والواجهات ومكتبات الأنواع بواسطة GUIDs في التسجيل، ضمن "HKEY_CLASSES_ROOT \ CLSID" للفئات و "HKEY_CLASSES_ROOT \ Interface" للواجهات. تستخدم مكتبات COM التسجيل لتحديد المكتبات المحلية الصحيحة لكل كائن COM أو موقع الشبكة لخدمة بعيدة.  COM خالية من التسجيل (RegFree COM) هي تقنية تم تقديمها مع نظام التشغيل Windows XP والتي تسمح لمكونات طراز كائن المكون (COM) بتخزين بيانات تعريف التنشيط و CLSID (codice_9) للمكون دون استخدام التسجيل. بدلاً من ذلك، يتم الإعلان عن بيانات التعريف ومعرفات CLSID للفئات المطبقة في المكون في بيان التجميع (الموصوف باستخدام XML)، ويتم تخزينه إما كمورد في الملف القابل للتنفيذ أو كملف منفصل مثبت مع المكون. يسمح ذلك بتثبيت إصدارات متعددة من نفس المكون في دلائل مختلفة، موصوفة بواسطة قوائمها الخاصة، بالإضافة إلى نشر XCOPY. هذه التقنية لها دعم محدود لخوادم EXE COM ولا يمكن استخدامها للمكونات على مستوى النظام مثل MDAC أو MSXML أو DirectX أو Internet Explorer .  أثناء تحميل التطبيق، يبحث مُحمل Windows عن البيان. إذا كان موجودًا، يضيف المُحمل معلومات منه إلى سياق التنشيط. عندما يحاول مصنع فئة COM إنشاء مثيل لفئة، يتم التحقق أولاً من سياق التنشيط لمعرفة ما إذا كان يمكن العثور على تنفيذ لـ CLSID. فقط في حالة فشل البحث، يتم فحص السجل.   يمكن أيضًا إنشاء كائنات COM يدويًا، بالنظر إلى مسار ملف DLL والمعرف الفريد العمومي للكائن. لا يتطلب ذلك تسجيل DLL أو GUID في سجل النظام، ولا يستخدم ملفات البيان. تصدير DLL COM دالة تسمى DllGetClassObject. يوفر استدعاء DllGetClassObject باستخدام GUID المطلوب و IID_IClassFactory مثيلًا لكائن المصنع. يحتوي كائن Factory على طريقة CreateInstance ، والتي يمكنها إنشاء مثيلات لكائن باستخدام واجهة GUID. هذه هي نفس العملية المستخدمة داخليًا عند إنشاء مثيلات لمكونات COM المسجلة.  إذا قام كائن COM الذي تم إنشاؤه بإنشاء كائن COM آخر باستخدام واجهة برمجة تطبيقات CoCreateInstance العامة، فسيحاول القيام بذلك بالطريقة العامة المعتادة، باستخدام التسجيل أو ملفات البيان. ولكن يمكنها إنشاء كائنات داخلية (قد لا يتم تسجيلها على الإطلاق)، وتوزع المراجع إلى واجهات باستخدام معرفتها الخاصة.  يمكن إنشاء كائنات COM بشفافية والإشارة إليها من داخل نفس العملية (قيد المعالجة)، عبر حدود العملية (خارج المعالجة)، أو عن بُعد عبر الشبكة (DCOM). تستخدم الكائنات خارج المعالجة والبعيدة التنظيم لإجراء تسلسل لاستدعاءات الأسلوب وإرجاع القيم عبر حدود العملية أو الشبكة. هذا التنظيم غير مرئي للعميل، والذي يصل إلى الكائن كما لو كان كائنًا محليًا قيد المعالجة.  في COM ، تتم معالجة الخيوط من خلال مفهوم يعرف باسم "الشقق". يعيش كائن COM الفردي في جزء واحد بالضبط، والذي قد يكون إما مترابطًا فرديًا أو متعدد الخيوط. هناك ثلاثة أنواع من الشقق في COM: شقة "أحادية الخيوط (STA)" ، "وشقة متعددة الخيوط (MTA)" ، "وشقة خيوط محايدة" (NA). تمثل كل شقة آلية واحدة حيث يمكن مزامنة الحالة الداخلية للكائن عبر خيوط متعددة. يمكن أن تتكون العملية من كائنات COM متعددة، قد يستخدم بعضها STA والبعض الآخر قد يستخدم MTA. وبالمثل، تعيش جميع مؤشرات الترابط التي تصل إلى كائنات COM في شقة واحدة. يتم تحديد اختيار الحيز لكائنات COM والخيوط في وقت التشغيل، ولا يمكن تغييره.  الخيوط والأشياء التي تنتمي إلى نفس الشقة تتبع نفس قواعد الوصول إلى مؤشر الترابط. لذلك يتم تنفيذ استدعاءات الأسلوب التي يتم إجراؤها داخل نفس الشقة مباشرةً دون أي مساعدة من COM. يتم تحقيق مكالمات الطريقة التي يتم إجراؤها عبر الشقق عن طريق التنظيم. هذا يتطلب استخدام الوكلاء والبروتين.  نظرًا لأن COM لديها تنفيذ معقد إلى حد ما ، يمكن أن يصرف المبرمجون عن بعض مشكلات «السباكة».  عند تهيئة STA ، فإنه ينشئ نافذة مخفية تُستخدم لتوجيه الرسائل بين الأقسام وبين العمليات. يجب أن يتم «ضخ» قائمة انتظار الرسائل بانتظام في هذه النافذة. يُعرف هذا البناء باسم «مضخة الرسائل». في الإصدارات السابقة من Windows ، قد يؤدي عدم القيام بذلك إلى توقف النظام على مستوى النظام. هذه المشكلة معقدة بسبب بعض واجهات برمجة تطبيقات Windows التي تقوم بتهيئة COM كجزء من تنفيذها ، مما يؤدي إلى «تسرب» تفاصيل التنفيذ.  قد يتسبب حساب المرجع داخل COM في حدوث مشكلات إذا تمت الإشارة بشكل دائري إلى كائنين أو أكثر. يجب أن يأخذ تصميم التطبيق ذلك في الاعتبار حتى لا تُترك الأشياء يتيمة. يمكن أيضًا ترك الكائنات مع عدد المراجع النشطة إذا تم استخدام طراز «مصدر الحدث» COM. نظرًا لأن الكائن الذي أطلق الحدث يحتاج إلى مرجع للكائن الذي يتفاعل مع الحدث ، فلن يصل عدد مرجع الأخير إلى الصفر أبدًا. عادةً ما يتم كسر الدورات المرجعية باستخدام إما إنهاء خارج النطاق أو هويات منفصلة. في تقنية الإنهاء خارج النطاق ، يكشف الكائن عن طريقة ، عند استدعائها ، تجبره على إسقاط إشاراته إلى كائنات أخرى ، وبالتالي كسر الحلقة. في تقنية الهوية المنقسمة ، يكشف تطبيق واحد عن كائنين COM منفصلين (يُعرفان أيضًا باسم الهويات). يؤدي هذا إلى إنشاء مرجع ضعيف بين كائنات COM ، مما يمنع دورة مرجعية.  نظرًا لأنه يتم تنفيذ مكونات COM قيد المعالجة في ملفات DLL ويسمح التسجيل فقط بإصدار واحد لكل CLSID ، فقد تخضع في بعض الحالات لتأثير "DLL Hell ". قدرة COM خالية من التسجيل يلغي هذه المشكلة للمكونات قيد التشغيل؛ لا يتوفر COM الخالي من التسجيل للخوادم خارج المعالجة.