Programavimas

Demeterizuojantis Demeterio dėsnio principą

Demeterio įstatymas (arba mažiausiai žinių principas) yra programinės įrangos kūrimo gairės. Pirmą kartą 1987 m. Šiaurės rytų universitete aptartas šis principas teigia, kad objektas niekada neturėtų žinoti kitų objektų vidinių detalių. Jis buvo sukurtas siekiant skatinti laisvą sujungimą programinės įrangos projektuose.

Atkreipkite dėmesį, kad susiejimą galima apibrėžti kaip programinės įrangos modulių tarpusavio priklausomybės laipsnį ir tai, kaip glaudžiai tokie moduliai yra sujungti vienas su kitu. Kuo daugiau sujungimų tarp komponentų yra programoje, tuo sunkiau jį modifikuoti ir prižiūrėti laikui bėgant. Visada yra gera praktika kurti sistemas, kurias lengviau išbandyti ir prižiūrėti užtikrinant, kad programos komponentai būtų laisvai sujungti. Daugiau apie sanglaudą ir susiejimą galite sužinoti iš mano straipsnio čia.

Suprasti Demetros dėsnio principą

Demeterio dėsnio principas teigia, kad modulis neturėtų žinoti apie objekto, kuriuo jis manipuliuoja, vidines detales. Kitaip tariant, programinės įrangos komponentas ar objektas neturėtų žinoti apie kitų objektų ar komponentų vidinį darbą. Supraskime Demeterio įstatymą su pavyzdžiu.

Apsvarstykite tris klases - A, B ir C - ir šių klasių objektus - atitinkamai objA, objB ir objC. Dabar tarkime, kad objA priklauso nuo objB, kuris savo ruožtu sudaro objC. Šioje scenoje objA gali remtis objB metodais ir savybėmis, bet ne objC.

Demeterio dėsnio principas naudoja kapsuliavimo pranašumus, kad pasiektų šį izoliavimą ir sumažintų jūsų programos komponentų susiejimą. Tai padeda pagerinti kodo kokybę ir skatina lankstumą bei paprastesnę kodo priežiūrą. Demeterio įstatymo laikymosi nauda yra ta, kad galite sukurti lengvai prižiūrimą ir pritaikomą būsimiems pokyčiams programinę įrangą.

Apsvarstykite C klasę, turinčią metodą M. Dabar tarkime, kad sukūrėte C klasės egzempliorių, pavadintą O. Demeterio įstatymas nurodo, kad metodas M gali iškviesti šiuos tipus. Arba klasės savybė turėtų iškviesti šį tipą tik narių:

  • Tas pats objektas, t. Y. Pats objektas „O“
  • Objektai, kurie buvo perduoti kaip argumentas metodui „M“
  • Vietiniai objektai, t. Y. Objektai, sukurti naudojant metodą „M“
  • Visuotiniai objektai, prieinami objektui „O“
  • Tiesioginiai objekto „O“ komponentiniai objektai

Štai kodų sąrašas, iliustruojantis klasę ir jos narius, kurie laikosi Demeterio įstatymo principo. Aiškumo sumetimais paminėjau komentarus visur, kur tai įmanoma.

viešosios klasės „LawOfDemeterExample“

    {

// Tai klasės srities egzempliorius

// ir todėl prie šio egzemplioriaus gali prisijungti visi šios klasės nariai

AnotherClass egzempliorius = new AnotherClass ();

public void „SampleMethodFollowingLoD“ (bandymo objektas)

        {         

Nieko nedaryk(); // Tai yra galiojantis skambutis, kai skambinate tos pačios klasės metodu

objekto duomenys = obj.GetData (); // Tai taip pat galioja, nes iškviečiate metodą

// egzemplioriuje, kuris buvo perduotas kaip parametras

int rezultatas = egzempliorius.GetResult (); // Tai taip pat galiojantis skambutis, kai skambinate jūs

// lokaliai sukurto egzemplioriaus metodas

        }

privatus negaliojantis „DoNothing“ ()

        {

// Čia parašykite kodą

        }

    }

Čia yra dar dvi klasės, kurių jums reikės norint sukompiliuoti aukščiau nurodytą kodą.

visuomenės klasė „AnotherClass“

    {

viešasis „GetResult“ ()

        {

grįžti -1;

        }

    }

viešosios klasės testas

    {

viešasis objektas „GetData“ ()

        {

return null;

        }

    }

Dabar žiūrėkite aukščiau pateiktą „LawOfDemeterExample“ klasę. Kodas savaime suprantamas. Dabar galite pagalvoti, ar Demetros įstatymas galioja tik metodams. Atsakymas yra „Ne“. Demeterio dėsnio principas galioja ir nuosavybėms.

Demeterio įstatymo principo pažeidimai

Pirmajame anksčiau paaiškintame kodo pavyzdyje diskusiją šia tema pradėjome laikydamiesi Demeterio įstatymo principo. Supraskime, kas nutinka, kai nesilaikome šio principo. Apsvarstykite šį kodo pavyzdį.

var duomenys = naujas A (). GetObjectB (). GetObjectC (). GetData ();

Šiame pavyzdyje klientas turės priklausyti nuo A, B ir C klasių. Kitaip tariant, jis yra susietas su A, B ir C klasių egzemplioriais. Jei ateityje šios klasės keistųsi, kiltų problemų, nes jūs veikiate pokyčius, kurie ateityje gali atsirasti bet kurioje iš šių klasių.

$config[zx-auto] not found$config[zx-overlay] not found