قانون دمیتر
قانونِ دمیتر∗ یا «قاعده حداقلِ دانش»∗ راهبردی در طراحی نرم‌افزار، بخصوص برنامه‌نویسی شی‌گراست. در شکلِ عمومی‌اش «دمیتر» (LoD)حالتِ خاصی از جفتگری ضعیف یا همراهی آزادانه است. این راهبرد در دانشگاه شمال‌شرقی در ۱۹۸۷ ایجاد و به صورتِ زیر خلاصه شده‌است:[۱]
- هر واحد باید اطلاعی اندک از سایر واحدها داشته باشد؛ البته تنها از واحدهایی که دارای رابطهٔ «نزدیک» با این واحد دارند،
- هر واحد تنها باید با دوستانش حرف زند؛ از غریبه‌ها دوری کن
- تنها با دوستِ نزدیکش حرف بزند
شالودهٔ این قانون آن است که تا حد ممکن هر شی از ساختار و ویژگی‌های هر چیزِ دیگری در سیستم ناآگاه باشد. این ناآگاهی شامل زیر-اجزائش نیز می‌شود. این قانون بخشی از پنهان‌سازی اطلاعات است. قانون نامش را از پروژه‌ایی به همین نام گرفته که پروژه‌ایی در سبکِ جنبه‌گرایی است. نام پروژه به افتخارِ دمیتر، «مادرِ توزیع» و «خدای کشاورزی» در اساطیر یونان نامگذاری شده بود. از جنبهٔ دیگر، بخاطر دیدگاهِ از «پایین به بالا» نامگذازی مناسب بود.
در برنامه‌نویسی شی‌گرا ویرایش
زمانی که قانون را بر روی برنامه‌های شی‌گرای اعمال می‌نماییم، می‌توان قانون را با نامِ صحیح‌ترش: «قانون دمیتر برای توایع/متدها» یاد کرد(LoD-F). در این حالت شی‌ایی مانند A می‌تواند یک سرویس (متد) از یک نمونهٔ شی‌ایی از B را درخواست نماید؛ ولی شیٰء A نمی‌تواند از طریقِ B به شیءِ دیگری، مانندِ C، دست‌پیدا نماید و سرویسی را دریافت نماید. جهتِ انجام این کار، شیءِ A به وضوح نیاز به دانشِ بیشتر از ساختارِ داخلیِ شیءِ B دارد. فاصلِ B نیازمندِ تغییر است تا در صورت لزوم بتواند نیازهایِ شیءِ A، را پاسخگو باشد. نیازی که دربارهٔ زی-اجزاء شیءِ B است. می‌توان در روشی جایگزینِ به شیءِ A اجازهٔ دسترسی مستقیم به شیءِ C را داد تا درخواستش را به‌طور مستقیم به شیءِ C دهد. در صورتِ رعایت قانونِ دمیتر، این تنها شیءِ B است که از ساختارِ داخلی‌اش آگاه است.
اگر تابعِ (متدِ) «m» از شیءِ «O» موردِ نیاز باشد؛ این فراخوانی تنها یکی از اشکالِ زیر است:[۲]
- خودِ
O - پارامترهایِ
m - شیءِ ایجاد/مورد نمونه‌برداری شدهٔ داخلِ متدِ
m - اجزاءِ اشیاءِ
Oبه صورتِ مستقیم - یک متغیرِ سراسری، که توسط شیءِ
O، در میدانِ کاریِmقرار دارد.
به صورِ دقیق‌تر، یک شیء، بهتر است تا از فراخوانی اعضای یک شیء که توسطِ متدِ دیگری پس فرستاده شده، خودداری نماید. به‌طور واضح‌تر، در زبان‌های جدید که از «.» برای فراخوانیِ متدِ یک شیء استفاده می‌کنند، می‌توان قانون را به صورتِ «تنها از یک نقطه استفاده کن» درآورد. قانونِ دمیتر درموردِ «a.b.Method()» شکسته شده. اما «a.Method()» نمایشی صحیح از قانون است. به عنوانِ یک مثالِ ساده؛ برای اینکه به یک اسب دستورِ حرکت دهیم؛ لازم نیست تا به هرپای اسب این دستور داده شود. اسب خودش دستور حرکت به پاهایش را صادر می‌کند.
برتری‌ها ویرایش
برتری قانونِ دمیتر در «قابلیت نگهداری» و «قابیلیت نطبیق» در نرم‌افزار است. از آنجا که اشیا وابستگیِ کمتری به ساختارِ اشیاء دیگر دارند، تغییرات در اشیا می‌تواند بدون نیاز به اطلاع به سایر اشیا صورت گیرد. بَسیلی و همکارانش[۳] نتایجِ عملی‌ایی را منتشر کردند که نشان می‌داد «پاسخِ برای یک کلاس» (پ.س. ک: تعداد متدهایی که دارای پتانسیلِ فراخوانی یک متد هستند) می‌تواند احتمالِ باگ نرم‌افزاری را کاهش دهد. با پیروی از قانونِ دمیتر می‌تواند «پ.س. ک» را کاهش دهد. درهر حال؛ مقدارِ «متدِ وزندار به ازای کلاس» (تعداد متدهای هر کلاس) را افزایش می‌دهد که خود باعث افزایشِ احتمالِ «باگ نرم‌افزاری» خواهد شد. معماریِ چندلایه‌ایی می‌تواند به عنوانِ سازوکارِ پیاده‌سازیِ قانونِ دمیتر در مهندسی نرم‌افزار باشد.
معایب ویرایش
در سطعِ متد، LoD، به سمتِ یک فاصلِ کمینه حرکت می‌کند؛ که باعثِ خواهد شد تا تنها اطلاعاتی که برایِ کارش نیاز دارد دسترسی داشته باشد که این شامل آگاهی اندکی از تعدادِ اندکی از متدهای سایر اشیایی است که با این شی رابطه نزدیک دارند.[۴] از طرفِ دیگر، در سطحِ کلاس LoD، منجر به بزرگ شدن فاصل خواهد شد؛ چراکه LoD نیازمندِ متدهای کمکی زیادی‌ست تا از ورودِ بیش از حد به داخلِ یک شی جلوگیری شود. راه‌حلی که برای این مسئله وجود دارد کمک گرفتن از رهیافتِ «برنامه‌نویسی جنبه‌گراست»[۵]
واژه‌نامه ویرایش
منابع ویرایش
- ↑ ماچِدو, امرسون. "README.markdown: Demeter". GitHub. Retrieved 2 فروردین 1392.
{{cite web}}: Check date values in:|accessdate=(help) - ↑ باک, دیوید. "The Paperboy, The Wallet, and The Law Of Demeter" (PDF). College of Computer and Information Science, Northeastern University. p. ۵. Retrieved 2 فروردین 1392.
{{cite web}}: Check date values in:|accessdate=(help) - ↑ Basili, Victor; Briand, L.; Melo, W. L. (۱۹۹۶–۱۰). "A Validation of Object-Oriented Design Metrics as Quality Indicators". IEEE Transactions on Software Engineering. ۲۲ (۱۰): ۷۵۱–۷۶۱.
{{cite journal}}: Check date values in:|date=(help) - ↑ Lieberherr, K.; Riel, A. (۱۹۸۸-۰۹-۲۵). "Object-Oriented Programming: An Objective Sense of Style" (PDF). OOPSLA '88 Proceedings. Archived from the original on 25 April 2013. Retrieved 2012-07-05.
Easier software maintenance, less coupling between your methods, better information hiding, narrower interfaces, methods which are easier to reuse, and easier correct.ness proofs using structural induction.
{{cite web}}: نگهداری یادکرد:ربات:وضعیت نامعلوم پیوند اصلی (link) - ↑ Lieberherr, Karl; Orleans, Doug; Ovlinger, Johan (2001). "ASPECT-ORIENTED PROGRAMMING WITH ADAPTIVE METHODS". COMMUNICATIONS OF THE ACM: ۳۹–۴۰. Archived from the original (PDF) on 21 February 2014. Retrieved 2012-07-05.
An adaptive method encapsulates the behavior of an operation into one place, thus avoiding the scattering problem, but also abstracts over the class structure, thus avoiding the tangling problem as well.
{{cite journal}}: Cite journal requires|journal=(help); Unknown parameter|month=ignored (help)
برایِ اطلاع بیشتر ویرایش
- Lieberherr, Karl; Holland, I. (September 1989). "Assuring good style for object-oriented programs". IEEE Software: ۳۸–۴۸.
- Lieberherr, Karl J. (1995). "Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns". Boston: PWS Publishing Company, International Thomson Publishing.
{{cite journal}}: Cite journal requires|journal=(help) - Hunt, Andrew; Thomas, David (2002). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley. pp. ۱۴۰–۱۴۱.
- Larman, Craig (2005). Applying UML and Patterns (3rd ed.). Prentice Hall. pp. ۴۳۰–۴۳۲. (from this book, "Law of Demeter" is also known as "Don't talk to strangers")
- McConnell, Steve (2004). Code Complete (2nd ed.). Microsoft Press. pp. ۱۵۰.
- Palermo, Jeffrey; Scheirman, Ben; Bogard, Jimmy (2009). ASP.NET MVC in Action. Manning Publications. pp. ۱۴.