قانون دمتر (اصل کمترین دانش)

سلام برنامه نویسان

اگر مدتی است که در حال کدنویسی بوده اید، احتمالاً با کدهایی مواجه شده اید که نگهداری یا گسترش آن دشوار است. اغلب، این اتفاق می افتد زیرا بخش هایی از سیستم اطلاعات زیادی در مورد یکدیگر دارند. آنجاست که قانون دمتر، یا اصل حداقل دانش، وارد بازی می شود.

این اصل در مورد کاهش وابستگی ها در کد شما و متمرکز نگه داشتن اشیا بر روی مسئولیت های خود است. به زبان ساده، می گوید که یک شی فقط باید با “دوستان” نزدیک خود صحبت کند، نه با غریبه ها یا دوستان دوستان. به نظر می رسد توصیه های اجتماعی است، اما برای کدهای تمیز و قابل نگهداری کاملاً کاربرد دارد!

قانون دمتر چیست؟

قانون دمتر (LoD) یک دستورالعمل طراحی برای توسعه نرم افزار، به ویژه در برنامه نویسی شی گرا است. ایده اصلی این است که یک متد از یک شی فقط باید متدهایی را روی اشیایی فراخوانی کند که مستقیماً با آن مرتبط هستند– به این معنی که برای گرفتن چیزهایی که نیاز دارید به اعماق زنجیره های اشیاء نرسید.

این اصل به کاهش کوپلینگ کمک می کند و تغییر و نگهداری کد شما را آسان تر می کند. با پیروی از این قانون، از وابستگی بیش از حد اجسام به عملکرد درونی اشیاء دیگر جلوگیری می‌کنید، که می‌تواند منجر به سیستم‌های شکننده شود که حتی با تغییرات کوچک هم می‌شکنند.

قانون اصلی

قانون اساسی قانون دمتر این است:

یک روش M از یک شی O فقط باید متدهای زیر را فراخوانی کرد:

• روش های O خود
• روش های اشیاء به عنوان آرگومان به M.
• روش های اشیایی که توسط M.
• روش های اشیایی که در متغیرهای نمونه نگهداری می شوند O.

اگر متوجه شدید که تماس های زنجیره ای مانند objectA.getB().getC().doSomething()، احتمالاً این اصل را نقض می کنید. ایده این است که این زنجیره را متوقف کنیم getB() یا زودتر

چرا باید مراقب باشیم؟

با پیروی از قانون Demeter، می توانید به طور قابل توجهی جفت شدن بین کلاس ها را کاهش دهید، که منجر به کدهای ماژولارتر و سازگارتر می شود. هنگامی که اشیاء اطلاعات کمتری در مورد عملکرد داخلی یکدیگر داشته باشند، سیستم قوی‌تر و کمتر مستعد شکستن در هنگام بازسازی می‌شود.

بیایید به یک مثال در سی شارپ نگاه کنیم تا این موضوع واضح تر شود.

مثال: نقض قانون دمتر

در اینجا یک سناریوی ساده وجود دارد که در آن قانون Demeter نقض می شود. فرض کنید یک داریم حقوق و دستمزد سیستمی که در آن حقوق یک کارمند به بودجه بخش آنها بستگی دارد.

public class Employee
{
    public Department Department { get; set; }
}

public class Department
{
    public Budget Budget { get; set; }
}

public class Budget
{
    public decimal SalaryCap { get; set; }
}

public class Payroll
{
    public decimal CalculateSalary(Employee employee)
    {
        // Violates Law of Demeter
        return employee.Department.Budget.SalaryCap * 0.5m;
    }
}

در CalculateSalary روش، ما در حال رسیدن به عمق Employee روابط شی برای دسترسی SalaryCap از Budget. این زنجیره فراخوانی متد، قانون دمتر را می شکند Payroll بیش از حد در مورد ساختار می داند Employee، Department، و Budget.

چگونه این را رفع کنیم؟

ما می‌توانیم این کد را با استفاده از عبارت Refactor کنیم قانون دمتر، هر کلاس را مسئول داده های خود می کند و تعاملات را محلی تر نگه می دارد.

public class Employee
{
    public Department Department { get; set; }

    public decimal GetSalaryCap()
    {
        return Department.GetSalaryCap();
    }
}

public class Department
{
    public Budget Budget { get; set; }

    public decimal GetSalaryCap()
    {
        return Budget.SalaryCap;
    }
}

public class Payroll
{
    public decimal CalculateSalary(Employee employee)
    {
        // Law of Demeter applied
        return employee.GetSalaryCap() * 0.5m;
    }
}

در حال حاضر، Payroll کلاس فقط با Employee به طور مستقیم، و Employee مسئول دانستن در مورد Department و Budget. این امر کوپلینگ را کاهش می دهد و سیستم را در برابر تغییر انعطاف پذیرتر می کند.

مزایای کلیدی قانون دمتر

1. کوپلینگ شل: هنگامی که کلاس ها کمتر در مورد یکدیگر می دانند، آنها کمتر به هم متصل می شوند و تغییرات را آسان تر و ایمن تر می کند.
2. تعمیر و نگهداری آسان تر: با وابستگی‌های کمتر، بازپرداخت ریسک بسیار کمتر می‌شود.
3. خوانایی بهبود یافته: درک جریان کد زمانی که اشیاء دارای مرزهای واضح و کمترین تعامل با اجسام دور هستند آسان تر است.
4. تست پذیری بهتر: کلاس‌هایی که از قانون دمتر پیروی می‌کنند اغلب راحت‌تر می‌توان آنها را به صورت مجزا مورد تمسخر و آزمایش قرار داد، زیرا به زنجیره‌های طولانی اشیاء وابسته نیستند.

افکار نهایی

را قانون دمتر ممکن است در ابتدا یک قانون سخت به نظر برسد، اما وقتی آن را به طور مداوم اعمال می کنید، واقعاً به نوشتن کد تمیز و قابل نگهداری کمک می کند. این شما را مجبور می کند که در مورد تعاملات شی فکر کنید و طراحی کلاس های کوچکتر و متمرکزتر را تشویق می کند.

با این حال، مانند هر اصل دیگری، کورکورانه از آن استفاده نکنید. در برخی موارد، اگر کد شما را بدون ایجاد ریسک زیاد ساده کند، ممکن است یک تخلف کوچک توجیه شود. همیشه طراحی تمیز را با اجرای عملی متعادل کنید.
به کدنویسی ادامه دهید!!