قانون ديميتر

قانون ديميتر ( LoD ) أو مبدأ أقل معرفة هو دليل تصميمي لتطوير البرمجيات ، وخاصة البرامج الموجهة للكائنات . في شكله العام، يُعدّ قانون ديميتر حالة خاصة من الترابط المنخفض . اقترح هذا الدليل إيان هولاند في جامعة نورث إيسترن في أواخر عام 1987، ^{[ 1 ]} وتُقدّم التوصيات الثلاث التالية ملخصًا موجزًا ​​له: ^{[ 2 ]}

1. ينبغي أن تمتلك كل وحدة معرفة محدودة فقط عن الوحدات الأخرى: فقط الوحدات "الوثيقة الصلة" بالوحدة الحالية.
2. ينبغي على كل وحدة التحدث فقط مع أصدقائها؛ لا تتحدثوا مع الغرباء.
3. تحدث فقط مع أصدقائك المقربين.

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

سُمّي بهذا الاسم نسبةً إلى أصله في مشروع ديميتر ، وهو جهدٌ في مجال البرمجة التكيفية والبرمجة الموجهة نحو الجوانب . سُمّي المشروع تكريمًا لديميتر ، "أم التوزيع" وإلهة الزراعة اليونانية ، للدلالة على فلسفة البرمجة التصاعدية التي تتجسد أيضًا في القانون نفسه. ^{[ 3 ]}

يعود قانون ديميتر إلى عام 1987 عندما اقترحه إيان هولاند لأول مرة، والذي كان يعمل على مشروع ديميتر. وكان هذا المشروع بمثابة مهد للعديد من مبادئ البرمجة الموجهة نحو الجوانب (AOP).

يبدو أن اقتباسًا في أحد أجزاء المشروع المتبقية يوضح أصول الاسم: ^{[ 4 ]}

ديميتر

إلهة الزراعة عند الإغريق.

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

ثم روجنا لفكرة أن تطوير البرمجيات على طريقة ديميتر يتمحور حول تنمية البرمجيات بدلاً من بنائها. وقد قدمنا ​​مفهوم خطة النمو، وهي عبارة عن سلسلة من مخططات فئات UML المتزايدة التعقيد.

تُعد خطط النمو مفيدة لبناء الأنظمة بشكل تدريجي.

يمكن للكائن aطلب خدمة (استدعاء دالة) من نسخة كائن آخر b، ولكن aلا ينبغي للكائن "الوصول" bإلى كائن آخر عبر كائن آخر cلطلب خدماته. فذلك يعني aضمنيًا أن الكائن الآخر يحتاج إلى معرفة أكبر bببنيته الداخلية.

بدلاً من ذلك، bينبغي تعديل واجهة 's إذا لزم الأمر بحيث يمكنها تلبية aطلب الكائن 's' مباشرةً، وتمريره إلى أي مكونات فرعية ذات صلة. أو بدلاً من ذلك، aيمكن أن يكون لـ 's' مرجع مباشر إلى الكائن 's' cوإرسال الطلب إليه مباشرةً. إذا تم اتباع القاعدة، فإن الكائن 's' فقط bهو من يعرف بنيته الداخلية.

بصورة أكثر رسمية، ينص قانون ديميتر للوظائف على أنه لا يجوز لطريقة mالكائن aاستدعاء طرق الأنواع التالية من الكائنات إلا: ^{[ 5 ]}

• aنفسها؛
• mمعلمات 's؛
• أي كائنات تم إنشاؤها داخل m؛
• aسمات 's؛
• المتغيرات العامة التي يمكن الوصول إليها من خلال aنطاق m.

على وجه الخصوص، ينبغي للكائن تجنب استدعاء توابع كائن آخر تم إرجاعه بواسطة تابع آخر. في العديد من لغات البرمجة الكائنية الحديثة التي تستخدم النقطة كمعرّف للحقل، يمكن صياغة القاعدة ببساطة على النحو التالي: "استخدم نقطة واحدة فقط". ^{[ 6 ]} أي أن الكود a.m().n()يخالف القاعدة حيث a.m()لا يخالفها. على سبيل المثال ، عندما نريد أن يمشي كلب، لا نأمر أرجل الكلب بالمشي مباشرةً؛ بل نأمر الكلب الذي بدوره يأمر أرجله.

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

نشر باسيلي وآخرون ^{[ 7 ]} نتائج تجريبية عام 1996 تشير إلى أن انخفاض معدل الاستجابة للفئة (RFC، أي عدد الطرق التي يُحتمل استدعاؤها عند استدعاء طريقة من تلك الفئة) يُمكن أن يُقلل من احتمالية حدوث أخطاء برمجية . ويمكن أن يؤدي اتباع قانون ديميتر إلى انخفاض معدل الاستجابة للفئة. مع ذلك، تُشير النتائج أيضًا إلى أن زيادة عدد الطرق المرجحة لكل فئة ^{[ 8 ]} (WMC، أي عدد الطرق المُعرّفة في كل فئة) يُمكن أن تزيد من احتمالية حدوث أخطاء برمجية. كما أن اتباع قانون ديميتر يُمكن أن يؤدي إلى زيادة عدد الطرق المرجحة لكل فئة.

يمكن اعتبار البنية متعددة الطبقات آلية منهجية لتطبيق قانون ديميتر في نظام برمجي. في هذه البنية، لا يمكن للبرنامج داخل كل طبقة استدعاء سوى البرامج داخل الطبقة نفسها والبرامج داخل الطبقة التي تليها. ويُعدّ "تجاوز الطبقات" انتهاكًا لهذه البنية.

على الرغم من أن مستوى التفاصيل يزيد من قدرة النظام البرمجي على التكيف، إلا أنه قد يؤدي إلى كتابة العديد من الدوال الوسيطة لنقل الاستدعاءات إلى المكونات؛ وفي بعض الحالات، قد يُضيف ذلك عبئًا ملحوظًا من حيث الوقت والمساحة. ^{[ 7 ] [ 9 ] [ 10 ]}

على مستوى الدوال، يؤدي مستوى التفاصيل (LoD) إلى واجهات محدودة، تتيح الوصول فقط إلى المعلومات اللازمة لأداء وظيفتها، حيث تحتاج كل دالة إلى معرفة مجموعة صغيرة من دوال الكائنات ذات الصلة الوثيقة. ^{[ 11 ]} من ناحية أخرى، على مستوى الأصناف، إذا لم يُستخدم مستوى التفاصيل بشكل صحيح، فقد يتم تطوير واجهات واسعة (أي موسعة) تتطلب إضافة العديد من الدوال المساعدة. ^{[ 9 ] [ 10 ]} ويعود ذلك إلى سوء التصميم وليس نتيجة لمستوى التفاصيل بحد ذاته. إذا تم استخدام دالة تغليف، فهذا يعني أن الكائن الذي يتم استدعاؤه من خلال دالة التغليف كان ينبغي أن يكون تابعًا في الصنف المُستدعي.

أحد الحلول المقترحة لمشكلة واجهات الفئات الموسعة هو النهج الموجه نحو الجوانب ^{[ 12 ]} ، حيث يُحدد سلوك الأسلوب كجانب على مستوى عالٍ من التجريد. تُدار الواجهات الواسعة من خلال لغة تحدد التطبيقات. تستخدم كل من استراتيجية الاجتياز والزائر التكيفي مجموعةً صغيرةً فقط من الفئات المشاركة في العملية، ويتم تجريد المعلومات المتعلقة بالروابط بين هذه الفئات.

• نمط الواجهة
• مبدأ أقل قدر من الدهشة
• مبدأ المسؤولية الواحدة

• قانون ديميتر (LoD)
• "البرمجة الموجهة للكائنات: حس موضوعي للأسلوب" (وقائع مؤتمر OOPSLA '88) (ملف PDF)
• ساعي البريد، والمحفظة، وقانون ديميتر (ملف PDF)
• فيل هاك: "قانون ديميتر ليس مجرد تمرين لعدّ النقاط"
• ليبر: "قانون ديميتر: مبدأ أقل قدر من المعرفة"
• "برمجيات كائنية التوجه تكيفية، طريقة ديميتر"
• مشروع ديميتر —- ما هو مشروع ديميتر؟