Demetrski zakon (ali načelo najmanjšega znanja) je smernica za oblikovanje programov. To načelo je bilo prvič obravnavano na severovzhodni univerzi leta 1987 in pravi, da predmet nikoli ne sme poznati notranjih podrobnosti drugih predmetov. Zasnovan je bil za spodbujanje ohlapnih sklopk pri oblikovanju programske opreme.
Upoštevajte, da je povezavo mogoče opredeliti kot stopnjo medsebojne odvisnosti med programskimi moduli in kako tesno so ti moduli med seboj povezani. Bolj ko je povezava med komponentami v aplikaciji, težje jo je spreminjati in vzdrževati skozi čas. Vedno je dobra praksa oblikovati sisteme, ki jih je lažje preizkusiti in vzdrževati, tako da zagotovite, da so komponente v aplikaciji ohlapno povezane. Več o koheziji in povezovanju lahko izveste iz mojega članka tukaj.
Razumevanje načela zakona Demetre
Načelo zakona Demetra določa, da modul ne bi smel imeti znanja o notranjih podrobnostih predmetov, s katerimi manipulira. Z drugimi besedami, programska komponenta ali predmet ne bi smel poznati notranjega delovanja drugih predmetov ali komponent. Razumejmo Demetrov zakon s primerom.
Upoštevajte tri razrede, in sicer - A, B in C - in predmete teh razredov - objA, objB in objC. Zdaj predpostavimo, da je objA odvisen od objB, ta pa sestavlja objC. V tem scenariju lahko objA prikliče metode in lastnosti objB, ne pa tudi objC.
Načelo zakona Demetra izkorišča enkapsulacijo, da doseže to izolacijo in zmanjša povezavo med komponentami vaše aplikacije. To pomaga izboljšati kakovost kode in spodbuja prilagodljivost in lažje vzdrževanje kode. Prednost upoštevanja Demetrovega zakona je v tem, da lahko zgradite programsko opremo, ki jo je mogoče enostavno vzdrževati in prilagoditi prihodnjim spremembam.
Razmislite o razredu C z metodo M. Zdaj predpostavimo, da ste ustvarili primerek razreda C z imenom O. Demetrov zakon določa, da lahko metoda M prikliče naslednje vrste .ali lastnost razreda mora priklicati naslednjo vrsto samo za člane:
- Isti predmet, torej sam objekt "O"
- Predmeti, ki so bili posredovani kot argument metodi “M”
- Lokalni predmeti, tj. Predmeti, ki so bili ustvarjeni znotraj metode "M"
- Globalni predmeti, do katerih lahko dostopa objekt „O“
- Neposredni sestavni predmeti predmeta „O“
Tu je seznam kod, ki ponazarja razred in njegove člane, ki se držijo načela zakona Demetre. Za jasnost sem omenil pripombe, kjer koli je to primerno.
javni razred LawOfDemeterExample
{
// To je primerek v obsegu razreda
// in tako lahko do tega primerka dostopajo vsi člani tega razreda
Primerek AnotherClass = nov AnotherClass ();
javna praznina SampleMethodFollowingLoD (Test obj)
{
Delati nič(); // To je veljaven klic, saj kličete metodo istega razreda
podatki o objektu = obj.GetData (); // To velja tudi, ker prikličete metodo
// na primerku, ki je bil poslan kot parameter
int rezultat = primer.GetResult (); // To je tudi veljaven klic, ko kličete
// metoda na primerku, ki je ustvarjen lokalno
}
zasebna praznina DoNothing ()
{
// Tukaj napiši nekaj kode
}
}
Tu sta še dva razreda, ki bi jih morali sestaviti zgornjo kodo.
javni razred AnotherClass
{
javni int GetResult ()
{
vrnitev -1;
}
}
test javnega razreda
{
javni objekt GetData ()
{
vrni null;
}
}
Zdaj se obrnite na razred LawOfDemeterExample, prikazan zgoraj. Koda je samoumevna. Zdaj se lahko vprašate, ali Demetrski zakon velja samo za metode. Odgovor je "Ne". Načelo zakona Demetra velja tudi za nepremičnine.
Kršitve zakonov Demetrskega zakona
V prvem primeru kode, ki je bil razložen prej, smo razpravo o tej temi začeli z upoštevanjem načela zakona Demetre. Razumejmo, kaj se zgodi, če tega načela ne upoštevamo. Razmislite o tem primeru kode.
var podatki = novo A (). GetObjectB (). GetObjectC (). GetData ();
V tem primeru bo odjemalec odvisen od razredov A, B in C. Z drugimi besedami, povezan je s primerki razredov A, B in C. Če se bodo ti razredi v prihodnosti spremenili, boste naleteli na težave, saj izpostavljate se spremembam, ki bi se v prihodnosti lahko pojavile v katerem koli od teh razredov.
