موضوع مقاله: قانون دمیتر | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # قانون دمیتر | مقدمه: قانونِ دمیتر یا «قاعده حداقلِ دانش» راهبردی در طراحی نرم‌افزار، به ویژه برنامه‌نویسی شی‌گراست. | ## بخش 1: قانون دمیتر | این راهبرد در دانشگاه شمال‌شرقی در ۱۹۸۷ ایجاد و به صورتِ زیر خلاصه شده‌است: هر واحد باید اطلاعی اندک از سایر واحدها داشته باشد؛ البته تنها از واحدهایی که دارای رابطهٔ «نزدیک» با این واحد دارند، هر واحد تنها باید با دوستانش حرف زند؛ از غریبه‌ها دوری کن تنها با دوستِ نزدیکش حرف بزند شالودهٔ این قانون آن است که تا حد ممکن هر شی از ساختار و ویژگی‌های هر چیزِ دیگری در سیستم ناآگاه باشد. قانون نامش را از پروژه‌ایی به همین نام گرفته که پروژه‌ایی در سبکِ جنبه‌گرایی است. نام پروژه به افتخارِ دمیتر، «مادرِ توزیع» و «خدای کشاورزی» در اساطیر یونان نامگذاری شده بود. در برنامه‌نویسی شی‌گرا زمانی که قانون را بر روی برنامه‌های شی‌گرای اعمال می‌نماییم، می‌توان قانون را با نامِ صحیح‌ترش: «قانون دمیتر برای توابع/متدها» یاد کرد(LoD-F). در این حالت شی‌ایی مانند A می‌تواند یک سرویس (متد) از یک نمونهٔ شی‌ایی از B را درخواست نماید؛ ولی شیٰء A نمی‌تواند از طریقِ B به شیءِ دیگری، مانندِ C، دست‌پیدا نماید و سرویسی را دریافت نماید. جهتِ انجام این کار، شیءِ A به وضوح نیاز به دانشِ بیشتر از ساختارِ داخلیِ شیءِ B دارد. فاصلِ B نیازمندِ تغییر است تا در صورت لزوم بتواند نیازهایِ شیءِ A، را پاسخگو باشد. | ## بخش 2: قانون دمیتر | می‌توان در روشی جایگزینِ به شیءِ A اجازهٔ دسترسی مستقیم به شیءِ C را داد تا درخواستش را به‌طور مستقیم به شیءِ C دهد. در صورتِ رعایت قانونِ دمیتر، این تنها شیءِ B است که از ساختارِ داخلی‌اش آگاه است. اگر تابعِ (متدِ) «m» از شیءِ «O» موردِ نیاز باشد؛ این فراخوانی تنها یکی از اشکالِ زیر است: خودِ O پارامترهایِ m شیءِ ایجاد/مورد نمونه‌برداری شدهٔ داخلِ متدِ m اجزاءِ اشیاءِ O به صورتِ مستقیم یک متغیرِ سراسری، که توسط شیءِ O، در میدانِ کاریِ m قرار دارد. به صورِ دقیق‌تر، یک شیء، بهتر است تا از فراخوانی اعضای یک شیء که توسطِ متدِ دیگری پس فرستاده شده، خودداری نماید. به‌طور واضح‌تر، در زبان‌های جدید که از «.» برای فراخوانیِ متدِ یک شیء استفاده می‌کنند، می‌توان قانون را به صورتِ «تنها از یک نقطه استفاده کن» درآورد. به عنوانِ یک مثالِ ساده؛ برای اینکه به یک اسب دستورِ حرکت دهیم؛ لازم نیست تا به همه پا های اسب این دستور داده شود. برتری‌ها برتری قانونِ دمیتر در «قابلیت نگهداری» و «قابیلیت نطبیق» در نرم‌افزار است. | ## بخش 3: قانون دمیتر | از آنجا که اشیا وابستگیِ کمتری به ساختارِ اشیاء دیگر دارند، تغییرات در اشیا می‌تواند بدون نیاز به اطلاع به سایر اشیا صورت گیرد. بَسیلی و همکارانش نتایجِ عملی‌ایی را منتشر کردند که نشان می‌داد «پاسخِ برای یک کلاس» (پ.س. ک: تعداد متدهایی که دارای پتانسیلِ فراخوانی یک متد هستند) می‌تواند احتمالِ باگ نرم‌افزاری را کاهش دهد. درهر حال؛ مقدارِ «متدِ وزن دار به ازای کلاس» (تعداد متدهای هر کلاس) را افزایش می‌دهد که خود باعث افزایشِ احتمالِ «باگ نرم‌افزاری» خواهد شد. معماریِ چندلایه‌ایی می‌تواند به عنوانِ سازوکارِ پیاده‌سازیِ قانونِ دمیتر در مهندسی نرم‌افزار باشد. معایب در سطح متد، LoD، به سمتِ یک فاصلِ کمینه حرکت می‌کند؛ که باعثِ خواهد شد تا تنها اطلاعاتی که برایِ کارش نیاز دارد دسترسی داشته باشد که این شامل آگاهی اندکی از تعدادِ اندکی از متدهای سایر اشیایی است که با این شی رابطه نزدیک دارند. | ## جمع‌بندی | از طرفِ دیگر، در سطحِ کلاس LoD، منجر به بزرگ شدن فاصل خواهد شد؛ چراکه LoD نیازمندِ متدهای کمکی زیادی‌ست تا از ورودِ بیش از حد به داخلِ یک شی جلوگیری شود.