סילוק עקרון חוק דמטר

חוק דמטר (או עקרון הידע הכי פחות) הוא קו מנחה לתכנון לפיתוח יישומי תוכנה. עיקרון זה נדון לראשונה באוניברסיטת נורת'איסטרן בשנת 1987, כי אובייקט לעולם אינו אמור לדעת את הפרטים הפנימיים של אובייקטים אחרים. הוא נועד לקדם צימוד רופף בעיצוב תוכנה.

שים לב שניתן להגדיר צימוד כמידת התלות ההדדית הקיימת בין מודולי תוכנה וכיצד קשר מודולים כאלה קשורים זה לזה. ככל שהזיווג בין הרכיבים ביישום יותר קשה לשנות ולתחזק אותו לאורך זמן. תמיד נוהג לתכנן מערכות קלות יותר לבדיקה ולתחזוקה על ידי הקפדה על רכיבים ביישום. תוכלו ללמוד עוד על לכידות והצמדה מהמאמר שלי כאן.

הבנת עקרון חוק דמטר

עקרון חוק הדמטר קובע כי למודול לא אמור להיות הידע על הפרטים הפנימיים של האובייקטים שהוא מפעיל. במילים אחרות, רכיב תוכנה או אובייקט לא צריכים להכיר את העבודה הפנימית של אובייקטים או רכיבים אחרים. בואו נבין את חוק דמטר לדוגמא.

שקול שלוש מחלקות כלומר - A, B ו- C - ואובייקטים של מחלקות אלה - objA, objB ו- objC בהתאמה. עכשיו נניח ש- objA תלוי ב- objB, שמציב את התנגדות objectC. בתרחיש זה, objA יכול להפעיל שיטות ותכונות של objB אך לא objC.

עקרון חוק הדמטר מנצל אנקפסולציה בכדי להשיג בידוד זה ולהפחית צימוד בין רכיבי היישום שלך. זה עוזר בשיפור איכות הקוד ומקדם גמישות ותחזוקת קוד קלה יותר. היתרון של שמירה על חוק דמטר הוא שתוכלו לבנות תוכנה הניתנת לתחזוקה בקלות ולהתאמה לשינויים עתידיים.

שקול מחלקה C עם שיטה M. כעת נניח שיצרת מופע של המחלקה C בשם O. חוק הדמטר מציין כי השיטה M יכולה להפעיל את הסוגים הבאים של. או מאפיין של מחלקה צריך להפעיל את הסוג הבא. של חברים בלבד:

  • אותו אובייקט, כלומר האובייקט "O" עצמו
  • אובייקטים שהועברו כטיעון לשיטה "M"
  • אובייקטים מקומיים, כלומר אובייקטים שנוצרו בשיטה "M"
  • אובייקטים גלובליים הנגישים באמצעות האובייקט "O"
  • אובייקטים רכיבים ישירים של האובייקט "O"

הנה רשימת קוד הממחישה כיתה וחבריה העומדים בעקרון חוק דמטר. הזכרתי הערות בכל מקום אפשרי לשם הבהירות.

public class LawOfDemeterExample

    {

        //This is an instance in the class scope

        //and hence this instance can be accessed by any members of this class

        AnotherClass instance = new AnotherClass();

       public void SampleMethodFollowingLoD(Test obj)

        {         

            DoNothing(); //This is a valid call as you are calling a method of the same class

             object data = obj.GetData(); //This is also valid since you are calling a method

            //on an instance that has been passed as a parameter           

             int result = instance.GetResult();  //This is also a valid call as you are calling

            //a method on an instance locally created

        }

        private void DoNothing()

        {

            // Write some code here

        }

    }

להלן שתי המחלקות האחרות שתצטרך להרכיב את הקוד שלעיל.

public class AnotherClass

    {

        public int GetResult()

        {

            return -1;

        }

    }

    public class Test

    {

        public object GetData()

        {

            return null;

        }

    }

כעת, עיין במחלקה LawOfDemeterExample המוצגת לעיל. הקוד מסביר את עצמו. כעת אתה יכול לתהות אם חוק דמטר חל רק על שיטות. התשובה היא "לא". עקרון חוק דמטר חל גם על נכסים.

הפרות עקרון של חוק דמטר

בדוגמת הקוד הראשונה שהוסברה קודם לכן, התחלנו את הדיון בנושא זה על ידי שמירה על עקרון חוק דמטר. בואו נבין מה קורה כשאנחנו לא פועלים לפי העיקרון הזה. שקול דוגמה לקוד זה.

var data = new A().GetObjectB().GetObjectC().GetData();

בדוגמה זו, הלקוח יצטרך להיות תלוי במחלקות A, B ו- C. במילים אחרות, הוא משולב למופעים של המחלקות A, B ו- C. אם בעתיד שיעורים אלה ישתנו, היית נתקל בבעיה כ אתה חושף את עצמך לשינויים שעשויים להתרחש בכל אחת מהשיעורים הללו בעתיד.