التعريف: يجب ألا يعتمد العميل على الواجهات التي لا يتطلبها ؛ يجب إنشاء اعتماد فئة واحدة على أخرى على أصغر واجهة.
تنشأ المشكلة: تعتمد الفئة A على الفئة B من خلال الواجهة I ، ويعتمد الفئة C على الفئة D من خلال الواجهة I.
الحل: اقسم الواجهة المتضخمة I إلى عدة واجهات مستقلة ، وإنشاء الفئة A والفئة C تنشئ تبعيات مع الواجهات التي يحتاجونها على التوالي. وهذا هو ، يتم اعتماد مبدأ عزل الواجهة.
دعنا نعطي مثالاً لتوضيح مبدأ عزل الواجهة:
معنى هذا الرقم هو: يعتمد الفئة A على الأساليب 1 ، والطريقة 2 ، والطريقة 3 في الواجهة I ، والفئة B هي تنفيذ الاعتماد على الفئة A. الفئة C يعتمد على الأساليب 1 ، والطريقة 4 ، والطريقة 5 في الواجهة I ، والفئة D هي تطبيق الاعتماد على الفئة C.
دعونا أولاً نلقي نظرة على مثال على انتهاك عزل الواجهة:
الواجهة العامة iworker {public void work () ؛ الفراغ العام EAT () ؛ } يقوم عامل الفئة العامة بتنفيذ iWorker {Override public void work () {// todo worker work} override public void eat () {// todo worker eat}} robot class public eat () {Override public void work () {// todo robot work} @override void eat () }}
نظرًا لأن الروبوتات لا تحتاج إلى تناول الطعام ، فإن iWorker تعتبر واجهة متضخمة. بالطبع ، يمكنك أيضًا التنفيذ على المدى القصير لطريقة EAT في فئة الروبوت ، ولكن هذا قد يسبب أخطاء غير متوقعة. على سبيل المثال ، إذا كانت طريقة EAT تحتاج إلى استهلاك عدد صناديق الغداء ، فستكون هناك ظاهرة غير صحيحة.
ما يلي هو التنفيذ المعدل:
الواجهة العامة iworker {public void work () ؛ } الواجهة العامة idiet {public void eat () ؛ } يقوم عامل الفئة العامة بتنفيذ iworker ، idiet {Override public void work () {// todo work} override public void eat () {// todo work}} robot class public kyorments iworker {Override public void work () {// todo work}}}}}}}}}}}
تلخيص:
1. يجب أن تكون الواجهة صغيرة قدر الإمكان ومتماسكة للغاية ، ولكن يجب أن تكون مناسبة وصعبة للغاية ويصعب الحفاظ عليها.
2. إذا تم تصميمه كواجهة متضخمة ، فيمكن عزله باستخدام وضع المحول.