مشكلة واجهة ثنائية هشة

أحد حلول مشكلة واجهة البرمجة الثنائية الهشة هو كتابة لغة برمجة تُدرك وجود هذه المشكلة، وتمنع حدوثها من الأساس. معظم لغات البرمجة الكائنية الموجهة المصممة خصيصًا، على عكس تلك المطورة من لغات سابقة، تُنشئ جميع جداول الإزاحة الخاصة بها عند تحميل المكتبة. وبالتالي، ستُلاحظ أي تغييرات في بنية المكتبة عند هذه المرحلة. أما لغات البرمجة الكائنية الموجهة الأخرى، مثل Self ، فتُنشئ كل شيء أثناء التشغيل عن طريق نسخ وتعديل الكائنات الموجودة في المكتبات، ولذلك لا تمتلك فئة أساسية قابلة للتأثر بالهشاشة. بعض اللغات، مثل Java ، توفر توثيقًا شاملًا حول التغييرات الآمنة التي يُمكن إجراؤها دون التسبب في مشاكل أمنية.

يتمثل حل آخر في كتابة ملف وسيط يسرد الإزاحات وغيرها من المعلومات من مرحلة التجميع، والمعروفة باسم البيانات الوصفية. ثم يستخدم الرابط هذه المعلومات لتصحيح نفسه عند تحميل المكتبة في التطبيق. وتفعل منصات مثل .NET ذلك.

مع ذلك، اختار السوق لغات برمجة مثل C++ التي تعتمد بالفعل على الموقع، وبالتالي تُظهر سلوكًا غير مرغوب فيه. في هذه الحالات، لا تزال هناك عدة حلول لهذه المشكلة. أحدها يُلقي العبء على مُطوّر المكتبة من خلال مطالبته بإدراج عدد من الكائنات "البديلة" تحسبًا لاحتياجه لإضافة وظائف إضافية في المستقبل (كما هو الحال في الهياكل المستخدمة في مكتبة DirectX ). يعمل هذا الحل بشكل جيد حتى تنفد هذه الكائنات البديلة، ومن غير المرغوب إضافة الكثير منها لأنها تستهلك مساحة كبيرة من الذاكرة.

يوفر Objective-C 2.0 متغيرات مثيل غير هشة من خلال وجود مستوى إضافي من التوجيه غير المباشر للوصول إلى متغيرات المثيل.

يُعدّ استخدام نمط الجسر (Bridge pattern )، المعروف أحيانًا باسم " Pimpl " (مؤشر إلى التنفيذ)، حلاً جزئيًا آخر. ويُعتبر إطار عمل Qt مثالًا على هذا النوع من التنفيذ. يُعرّف كل صنف عضو بيانات واحدًا فقط، وهو مؤشر إلى البنية التي تحتوي على بيانات التنفيذ. من غير المرجح أن يتغير حجم المؤشر نفسه (بالنسبة لمنصة معينة)، لذا فإن تغيير بيانات التنفيذ لا يؤثر على حجم البنية العامة. مع ذلك، لا يمنع هذا حدوث تغييرات أخرى قد تُؤدي إلى حدوث أعطال، مثل إضافة توابع افتراضية إلى صنف لا يحتوي على توابع افتراضية، أو تغيير مخطط الوراثة.

يتطلب حل آخر مُرَبطًا أكثر ذكاءً. في الإصدار الأصلي من Objective-C ، سمح تنسيق المكتبة بوجود إصدارات متعددة من مكتبة واحدة، وتضمن بعض الوظائف لاختيار المكتبة المناسبة عند استدعائها. مع ذلك، لم تكن هذه الوظيفة ضرورية دائمًا، لأن الإزاحات كانت مطلوبة فقط للحقول، حيث كانت إزاحات الدوال تُجمع أثناء التشغيل، وبالتالي لا تُسبب أخطاءً في التحقق من صحة البيانات. ولأن الدوال تميل إلى التغيير بوتيرة أسرع من الحقول، لم تكن Objective-C تعاني من مشاكل كثيرة في التحقق من صحة البيانات، وكان بالإمكان تصحيح المشاكل التي ظهرت باستخدام نظام الترقيم. أضاف الإصدار 2.0 من Objective-C "وقت تشغيل حديثًا" حلّ مشكلة التحقق من صحة البيانات للحقول أيضًا. بالإضافة إلى ذلك، تستخدم لغة TOM إزاحات مُجمّعة أثناء التشغيل لكل شيء، مما يجعل التحقق من صحة البيانات مستحيلاً.

يُعدّ استخدام المكتبات الثابتة بدلاً من المكتبات الديناميكية، كلما أمكن، حلاً آخر، إذ لا يمكن تعديل المكتبة الثابتة إلا بإعادة تجميع التطبيق وتحديث الإزاحات المستخدمة. مع ذلك، تعاني المكتبات الثابتة من مشاكلها الخاصة، مثل حجمها الكبير وعدم القدرة على استخدام الإصدارات الأحدث منها تلقائيًا عند طرحها.

في هذه اللغات، يتم تقليل المشكلة عن طريق فرض الوراثة الفردية (لأن هذا يقلل من تعقيد شجرة الوراثة)، وعن طريق استخدام الواجهات بدلاً من الفئات الأساسية ذات الوظائف الافتراضية ، حيث أن الواجهات نفسها لا تحتوي على تعليمات برمجية، بل مجرد ضمان بأن كل توقيع طريقة تعلنه الواجهة سيكون مدعومًا من قبل كل كائن ينفذ الواجهة.

يزول كل هذا الإشكال إذا كان الكود المصدري للمكتبات متاحًا. حينها، يكفي إعادة تجميع بسيطة لحل المشكلة.