البرمجة القائمة على الواجهات

الموسوعة الحرة

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

تُعرّف البرمجة القائمة على الواجهات التطبيقَ على أنه مجموعة من المكونات، حيث لا يمكن إجراء استدعاءات واجهة برمجة التطبيقات (API) بين المكونات إلا من خلال واجهات مجردة، وليس من خلال فئات ملموسة. وعادةً ما يتم الحصول على نسخ من الفئات من خلال واجهات أخرى باستخدام تقنيات مثل نمط المصنع .

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

يمكن استخدام بنية قائمة على الواجهات عندما تقوم جهات خارجية - أو حتى فرق منفصلة داخل نفس المؤسسة - بتطوير مكونات أو إضافات لنظام قائم. تُعد قاعدة بيانات Eclipse IDE مثالًا على البرمجة القائمة على الواجهات. كل ما على موردي إضافات Eclipse فعله هو تطوير مكونات تُلبي متطلبات الواجهة التي حددتها مؤسسة Eclipse، وهي الجهة الأم لتطبيق Eclipse. في الواقع، حتى المكونات الأصلية في Eclipse، مثل أدوات تطوير Java، هي نفسها إضافات. يشبه هذا إلى حد ما قيام مُصنِّع هواتف محمولة بتحديد واجهة شاحن (ترتيب الدبابيس، جهد التيار المستمر المتوقع ، إلخ)، ثم قيام كل من المُصنِّع والجهات الخارجية بتصنيع شواحن هواتف محمولة خاصة بهم تتوافق مع مواصفات هذه الواجهة القياسية.  

تطور البرمجيات في البرمجة القائمة على الواجهات

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

  1. قد يتم تطوير واجهة جديدة بوظائف إضافية، والتي قد ترث من الواجهة القديمة
  2. قد يتم إبلاغ مطوري واجهات المستخدم بسياسة إصدار البرامج ، مثل الإصدار الدلالي 2.0 ، للسماح بإجراء تغييرات غير متوافقة مع الإصدارات اللاحقة، أو حتى غير متوافقة مع الإصدارات السابقة، في الإصدارات "الرئيسية" المستقبلية للمنصة.

تم استخدام كلا النهجين في منصة جافا.

التصميم بموجب عقد

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

انظر أيضاً

مراجع