مبدأ فصل الواجهة ، يدعو مبدأ عزل واجهة ISP إلى أن استخدام واجهات مخصصة متعددة أفضل من استخدام واجهة كاملة واحدة.
يجب إنشاء اعتماد فئة واحدة على فئة أخرى على أصغر واجهة.
تمثل الواجهة دورًا ، ويجب عدم تسليم الأدوار المختلفة إلى واجهة. يتم دمج الواجهات غير ذات الصلة معًا لتشكيل واجهة كبيرة متضخمة ، وهي تلوث بالدور والواجهة.
"لا ينبغي إجبار العملاء على الاعتماد على الأساليب التي لا يستخدمونها. الواجهات تنتمي إلى العملاء ، وليس التسلسل الهرمي للصف الذي هم فيه." هذا واضح جدا. بعبارات بسيطة ، لا تجبر العملاء على استخدام الأساليب التي لا يستخدمونها. إذا اضطر المستخدمون إلى استخدام الأساليب التي لا يستخدمونها ، فسيواجه هؤلاء العملاء تغييرات ناتجة عن التغييرات في هذه الطرق التي لا يستخدمونها.
في حالة الاستخدام ، قدم الطرق التي يحتاجها المتصل والأساليب غير الضرورية. يلتقي مبدأ عزل الواجهة. على سبيل المثال ، في نظام التجارة الإلكترونية ، هناك ثلاثة أماكن سيتم استخدامها في فئة الطلب.
وفقًا لمبدأ عزل الواجهة (ISP) ، ينبغي إنشاء اعتماد فئة واحدة على فئة أخرى على أصغر واجهة.
وهذا يعني ، بالنسبة للبوابة ، يمكن أن يعتمد فقط على واجهة مع طريقة الاستعلام.
هيكل UML كما يلي:
دعونا نلقي نظرة على مثال على كتابة واجهة Java التي تتجاهل مبدأ عزل الواجهة:
الواجهة I {public void method1 () ؛ طريقة الفراغ العام 2 () ؛ طريقة الفراغ العام 3 () ؛ طريقة الفراغ العام 4 () ؛ طريقة الفراغ العام 5 () ؛ } class a {public void repar1 (i i) {i.method1 () ؛ } public void repar2 (i i) {i.method2 () ؛ } public void repar3 (i i) {i.method3 () ؛ }} class B تنفذ i {public void method1 () {system.out.println ("method1" لتنفيذ الواجهة i ") ؛} method public void method2 () {system.out.println (" method 2 of class b interface i ") ؛ Method 4 و Method 5 مطلوبة ، ولكن نظرًا لوجود هاتين الطريقتين في الواجهة A ، // في عملية التنفيذ ، حتى لو كانت طريقة هاتين الطريقتين فارغة ، يجب تنفيذ هذه الطريقتين الفراغين العامين () } public void repar3 (i i) {i.method5 () ؛ } // للفئة D و Method2 و Method3 غير مطلوبة ، ولكن نظرًا لوجود هاتين الطريقتين في الواجهة A ، // لذلك ، حتى لو كان جسم الطريقة لهاتين الطريقتين فارغتين أثناء عملية التنفيذ ، يجب تنفيذ هاتين الطريقتين اللتين لا يوجد له تأثير. method public void method2 () {} public void method3 () {} public void method4 () {system.out.println ("الطريقة 4 من الفئة D ينفذ الواجهة i") ؛ } public void method5 () {system.out.println ("الطريقة 5 من الفئة D تنفذ الواجهة i") ؛ }} client client {public static void main (string [] args) {a a = new a () ؛ A.Depend1 (New B ()) ؛ A.Depend2 (New B ()) ؛ A.Depend3 (New B ()) ؛ C C = جديد C () ؛ C.Depend1 (New D ()) ؛ c.depend2 (new d ()) ؛ c.depend3 (new d ()) ؛ }} يمكن ملاحظة أنه إذا كانت الواجهة متضخمة للغاية ، طالما ظهرت الأساليب في الواجهة ، بغض النظر عما إذا كانت مفيدة للفئات التي تعتمد عليها ، فيجب تنفيذ هذه الطرق في فئة التنفيذ. من الواضح أن هذا ليس تصميمًا جيدًا. إذا تم تعديل هذا التصميم للامتثال لمبدأ عزل الواجهة ، فيجب تقسيم الواجهة. هنا نقسم الواجهة الأصلية I إلى ثلاث واجهات. يظهر تصميم الانقسام في الشكل أدناه:
كالعادة ، قم بنشر رمز البرنامج للرجوع إليه للأصدقاء الذين ليسوا على دراية برسم التخطيط للفصل:
الواجهة i1 {public void method1 () ؛ } الواجهة i2 {public void method2 () ؛ طريقة الفراغ العام 3 () ؛ } الواجهة i3 {public void method4 () ؛ طريقة الفراغ العام 5 () ؛ } class a {public void repar1 (i1 i) {i.method1 () ؛ } public void repar2 (i2 i) {i.method2 () ؛ } public void repar3 (i2 i) {i.method3 () ؛ }} Class B تنفذ i1 ، i2 {public void method1 () {system.out.println ("الطريقة 1 من الفئة B تنفذ الواجهة i1") ؛ } public void method2 () {system.out.println ("الطريقة 2 من الفئة B تنطلق الواجهة i2") ؛ } public void method3 () {system.out.println ("الطريقة 3 من الفئة B تنطلق الواجهة i2") ؛ }} class c {public void repar1 (i1 i) {i.method1 () ؛ } public void repar2 (i3 i) {i.method4 () ؛ } public void repar3 (i3 i) {i.method5 () ؛ }} class d تنفذ i1 ، i3 {public void method1 () {system.out.println ("الطريقة 1 من الفئة D تنفذ الواجهة i1") ؛ } public void method4 () {system.out.println ("الطريقة 4 من الفئة D تنفذ الواجهة i3") ؛ } public void method5 () {system.out.println ("الطريقة 5 من الفئة D تنفذ الواجهة i3") ؛ }} معنى مبدأ عزل الواجهة هو: إنشاء واجهة واحدة ، لا تنشئ واجهة ضخمة وممتدة ، ومحاولة تحسين الواجهة ، ومحاولة أقل من طرق في الواجهة. بمعنى آخر ، نحتاج إلى إنشاء واجهة مخصصة لكل فصل ، بدلاً من محاولة إنشاء واجهة ضخمة لجميع الفئات التي تعتمد عليها للاتصال. في هذا المثال ، يتم اعتماد مبدأ عزل الواجهة عند تغيير واجهة ضخمة إلى ثلاث واجهات مخصصة. في البرمجة ، يكون الاعتماد على العديد من الواجهات المخصصة أكثر مرونة من الاعتماد على واجهة شاملة واحدة. الواجهات هي "عقود" محددة للإعدادات الخارجية أثناء التصميم. من خلال تحديد واجهات متعددة ، يمكن منع انتشار التغييرات الخارجية ويمكن تحسين مرونة النظام وصيانته.
عند الحديث عن هذا ، سيشعر الكثير من الناس أن مبدأ عزل الواجهة يشبه إلى حد كبير مبدأ المسؤولية الفردية السابقة ، لكنه ليس كذلك. أولاً ، يركز مبدأ المسؤولية الفردية على المسؤوليات ؛ بينما يركز مبدأ عزل الواجهة على عزل اعتماد الواجهة. ثانياً ، مبدأ المسؤولية الفردية هو فصول القيود بشكل أساسي ، تليها واجهات وطرق ، والتي تهدف إلى التنفيذ والتفاصيل في البرنامج ؛ في حين أن مبدأ عزل الواجهة يقيد بشكل أساسي واجهات الواجهة ، ويهدف بشكل أساسي إلى التجريد ، ويهدف إلى بناء إطار البرنامج العام.
عند استخدام مبدأ عزل الواجهة لتقييد الواجهات ، يجب الانتباه إلى النقاط التالية:
يجب أن تكون الواجهة صغيرة قدر الإمكان ، ولكن يجب أن تكون محدودة. إن تحسين الواجهة يمكن أن يحسن مرونة البرمجة هو حقيقة أنها غير مربحة ، ولكن إذا كانت صغيرة جدًا ، فسيؤدي ذلك إلى الكثير من الواجهات وتعقيد التصميم. لذلك يجب أن تكون معتدلة.
الخدمات المخصصة للفئات التي تعتمد على الواجهات ، فقط الطرق التي يجب تعرضها للفئة المسمى ، والطرق التي لا تحتاجها مخفية. فقط من خلال التركيز على توفير خدمات مخصصة لوحدة نمطية ، يمكنك إنشاء علاقة تبعية الحد الأدنى.
تحسين التماسك وتقليل التفاعلات الخارجية. استخدم أقل كمية من الواجهة لإنجاز معظم الأشياء.
عند استخدام مبدأ عزل الواجهة ، يجب أن يكون معتدلاً. ليس من الجيد أن يكون لديك تصميم كبير جدًا أو صغير جدًا. عند تصميم واجهات ، فقط من خلال قضاء المزيد من الوقت في التفكير والتخطيط ، يمكن ممارسة هذا المبدأ بدقة.