Demeterov zákon (alebo princíp najmenších znalostí) je návrhové usmernenie pre vývoj softvérových aplikácií. Táto zásada, o ktorej sa prvýkrát diskutovalo na Northeastern University v roku 1987, uvádza, že objekt by nikdy nemal poznať vnútorné podrobnosti ostatných objektov. Bol navrhnutý na podporu voľnej väzby v softvérových dizajnoch.
Upozorňujeme, že väzbu možno definovať ako stupeň vzájomnej závislosti, ktorá existuje medzi softvérovými modulmi a ako úzko sú tieto moduly navzájom spojené. Čím je väzba medzi komponentmi v aplikácii silnejšia, tým je ťažšie ju v priebehu času upravovať a udržiavať. Navrhovanie systémov, ktoré sa dajú ľahšie testovať a udržiavať zabezpečením, že sú komponenty aplikácie voľne spojené, je vždy dobrým zvykom. Viac informácií o súdržnosti a väzbe sa dozviete z môjho článku tu.
Pochopenie princípu Demeterovho zákona
Princíp zákona Demeter hovorí, že modul by nemal mať vedomosti o vnútorných detailoch objektov, s ktorými manipuluje. Inými slovami, softvérový komponent alebo objekt by nemal mať znalosti o vnútornom fungovaní iných objektov alebo komponentov. Poďme pochopiť Demeterov zákon na príklade.
Zvážte tri triedy, konkrétne - A, B a C - a objekty týchto tried - objA, objB a objC. Teraz predpokladajme, že objA je závislá na objB, ktorá zase skladá objC. V tomto scenári môže objA vyvolať metódy a vlastnosti objB, ale nie objC.
Princíp zákona Demeter využíva zapuzdrenie na dosiahnutie tejto izolácie a na zníženie väzby medzi komponentmi vašej aplikácie. To pomáha pri zlepšovaní kvality kódu a podporuje flexibilitu a ľahšiu údržbu kódu. Výhodou dodržiavania zákona Demeter je, že môžete vytvárať softvér, ktorý je ľahko udržiavateľný a prispôsobiteľný budúcim zmenám.
Zvážte, že trieda C má metódu M. Teraz predpokladajme, že ste vytvorili inštanciu triedy C s názvom O. Zákon Demetera určuje, že metóda M môže vyvolať nasledujúce typy. Alebo vlastnosť triedy by mala vyvolať nasledujúci typ iba pre členov:
- Rovnaký objekt, t. J. Samotný objekt „O“
- Objekty, ktoré boli odovzdané ako argument metóde „M“
- Lokálne objekty, t. J. Objekty, ktoré boli vytvorené vo vnútri metódy „M“
- Globálne objekty, ktoré sú prístupné objektu „O“
- Priame zložkové objekty objektu „O“
Tu je zoznam kódov, ktorý ilustruje triedu a jej členov, ktorí sa riadia zásadou Demeterovho zákona. Kvôli prehľadnosti som spomenul komentáre, kdekoľvek je to vhodné.
verejná trieda LawOfDemeterExample
{
// Toto je inštancia v rozsahu triedy
// a teda k tejto inštancii majú prístup všetci členovia tejto triedy
Inštancia AnotherClass = nová AnotherClass ();
public void SampleMethodFollowingLoD (testovací objekt)
{
Nerob nič(); // Toto je platné volanie, pretože voláte metódu rovnakej triedy
data objektu = obj.GetData (); // Platí to aj preto, že voláte metódu
// na inštanciu, ktorá bola odovzdaná ako parameter
int vysledok = instance.GetResult (); // Toto je tiež platné volanie, keď voláte
// metóda na inštancii lokálne vytvorenej
}
private void DoNothing ()
{
// Sem napíš nejaký kód
}
}
Tu sú ďalšie dve triedy, ktoré by ste potrebovali na zostavenie vyššie uvedeného kódu.
verejná trieda AnotherClass
{
public int GetResult ()
{
návrat -1;
}
}
test verejnej triedy
{
verejný objekt GetData ()
{
návrat null;
}
}
Teraz sa obráťte na triedu LawOfDemeterExample uvedenú vyššie. Kód je samozrejmý. Možno by vás teraz zaujímalo, či sa Demeterov zákon vzťahuje iba na metódy. Odpoveď je „nie“. Princíp zákona Demeter platí aj pre nehnuteľnosti.
Porušenie zásad Demeterovho zákona
V prvom príklade kódu, ktorý sme vysvetlili skôr, sme začali diskusiu na túto tému dodržiavaním princípu Demeterovho zákona. Poďme si uvedomiť, čo sa stane, keď nebudeme dodržiavať túto zásadu. Zvážte tento príklad kódu.
var data = new A (). GetObjectB (). GetObjectC (). GetData ();
V tomto príklade bude klient závisieť od tried A, B a C. Inými slovami, je spojený s inštanciami tried A, B a C. Ak sa v budúcnosti tieto triedy zmenia, narazili by ste na problémy, pretože vystavujete sa zmenám, ktoré sa v budúcnosti môžu vyskytnúť v ktorejkoľvek z týchto tried.
