إن نمط محدد موقع الخدمة service locator pattern هو نمط تصميم design pattern يستخدم في تطوير البرمجيات لتغليفencapsulate العمليات التي ينطوي عليها الحصول على خدمة ذات طبقة تجريد قويةstrong abstraction layer. يستخدم هذا النمط سجلاً مركزيًا central registry يُعرف باسم "محدد الخدمة" "service locator"، والذي يقوم عند الطلب on request بإرجاع returns المعلومات اللازمة لأداء مهمة معينة. [1] يقول مؤيدو النمط إن هذا النهج يبسط التطبيقات القائمة على المكونات simplifies component-based applications حيث يتم سرد جميع listed التبعيات بشكل نظيفcleanly في بداية تصميم التطبيق بالكامل ، وبالتالي جعل حقن التبعية التقليدية طريقة أكثر تعقيدًا لتوصيل الكائناتconnecting objects. يجادل منتقدو النمط أنه نمط مضاد يحجب التبعيات obscures dependencies ويجعل اختبار البرمجيات أصعب. [2]
مزايا
- يمكن أن يعمل "محدد الخدمة""service locator" بمثابة رابط linkerبسيط لوقت التشغيل run-time. هذا يسمح بإضافة كود في وقت التشغيل دون إعادة تجميع re-compiling التطبيق ، وفي بعض الحالات دون الحاجة إلى إعادة تشغيلهrestart .
- يمكن للتطبيقات تحسين نفسها في وقت التشغيل عن طريق إضافة العناصر وإزالتها بشكل انتقائيselectively من محدد الخدمة. على سبيل المثال ، يمكن للتطبيق أن يكتشف أن لديه مكتبة أفضل لقراءة صور JPG المتاحة من المكتبة الافتراضية ، وتغيير السجل registry وفقًا لذلك.
- يمكن فصل أقسام كبيرة من مكتبة أو تطبيق بالكامل. الرابط الوحيد بينهما يصبح السجلregistry.
- قد يستخدم التطبيق العديد من محددات الخدمة المنظمةmultiple structured service locators التي تم إنشاؤها لوظيفة / اختبار functionality/testing معين. لا يحدد محدد موقع الخدمة صنف ثابت واحد( does not mandate one single static class) لكل عملية
- قد يكون الحل أبسط مع محدد موقع الخدمة (ضد حقن التبعية) في التطبيقات ذات التصميم الجيد للمكونات / الخدمة. في هذه الحالات ، يمكن اعتبار العيوب ميزة بالفعل (على سبيل المثال ، لا حاجة إلى توفير تبعيات مختلفة لكل صنف واصلاح تكوينات التبعيةmaintain dependency configurations)
سلبيات
- يقوم السجل registry بإخفاء تبعيات الصنف، مما يتسبب في أخطاء وقت التشغيل run-time errors بدلاً من أخطاء وقت التجميع compile-time errors عندما تكون التبعيات مفقودة (على غرار استخدام التبعية ). لكن كل مكتبة يتم تجميعها compiled، فقط اكتشاف الصنف الملموس concrete Class قد لا يتم العثور عليه و ينتج خطئ make error، إنها مشكلة نشرdeployment issue أكثر من مشكلة محدد الخدمةService Locator issue.
- يجعل السجل registry الكودcode أصعب للاختبار، نظرًا لأن جميع الاختبارات تحتاج إلى التفاعل مع نفس الصنف محدد الخدمة العالمية same global service locator class لتعيينset التبعيات المزيفة fake dependencies للصنف الذي ما زال قيد الاختبار. ومع ذلك ، يمكن التغلب على ذلك بسهولة عن طريق حقن أصناف التطبيق injecting application classes بواجهة تحديد موقع خدمة واحدة single service locator interface. يمكن تنفيذimplemented المحاكيSimulator لمحاكاة كل واجهة يوفرها محدد الخدمة ، لذلك من السهل تبديل التنفيذ الحقيقي بمحاكي.
مقالات ذات صلة
- حقن التبعية
- مبدأ انعكاس التبعية
- تسمية جافا وواجهة الدليل
المراجع
- Inversion of Control Containers and the Dependency Injection pattern - تصفح: نسخة محفوظة 2020-05-30 على موقع واي باك مشين.
- Seemann, Mark. "Service Locator is an Anti-Pattern". blog.ploeh.dk (باللغة الإنجليزية). مؤرشف من الأصل في 27 يونيو 201901 يونيو 2017.