The Law of Demeter (eller prinsippet om minst kunnskap) er en designretningslinje for utvikling av programvare. Først diskutert ved Northeastern University i 1987, sier dette prinsippet at et objekt aldri skal vite de indre detaljene til andre objekter. Den ble designet for å fremme løs kobling i programvaredesign.
Merk at kobling kan defineres som graden av gjensidig avhengighet som eksisterer mellom programvaremoduler og hvor nært slike moduler er koblet til hverandre. Jo mer koblingen mellom komponentene i en applikasjon, jo vanskeligere blir det å modifisere og vedlikeholde den over tid. Det er alltid en god praksis å designe systemer som er enklere å teste og vedlikeholde ved å sikre at komponentene i en applikasjon er løst koblet. Du kan lære mer om samhørighet og kobling fra artikkelen min her.
Å forstå Demeter-prinsippet
Law of Demeter-prinsippet sier at en modul ikke skal ha kunnskap om de indre detaljene til gjenstandene den manipulerer. Med andre ord, en programvarekomponent eller et objekt skal ikke ha kunnskap om den interne virkningen av andre objekter eller komponenter. La oss forstå Demeterloven med et eksempel.
Tenk på tre klasser, nemlig - A, B og C - og objekter av disse klassene - henholdsvis objA, objB og objC. Anta nå at objA er avhengig av objB, som igjen komponerer objC. I dette scenariet kan objA påkalle metoder og egenskaper til objB, men ikke objC.
Law of Demeter-prinsippet utnytter innkapsling for å oppnå denne isolasjonen og redusere koblingen mellom komponentene i applikasjonen. Dette hjelper til med å forbedre kodekvaliteten og fremmer fleksibilitet og enklere vedlikehold av koden. Fordelen med å overholde Demeter Law er at du kan bygge programvare som er lett å vedlikeholde og kan tilpasses fremtidige endringer.
Tenk på en klasse C som har en metode M. Anta at du har opprettet en forekomst av klassen C med navnet O. Demeterloven spesifiserer at metoden M kan påkalle følgende typer .eller en egenskap til en klasse skal påkalle følgende type bare av medlemmene:
- Det samme objektet, dvs. objektet “O” i seg selv
- Objekter som er sendt som et argument til metoden “M”
- Lokale objekter, dvs. objekter som er opprettet i metoden “M”
- Globale objekter som er tilgjengelige med objektet "O"
- Direkte komponentobjekter av objektet “O”
Her er en kodeliste som illustrerer en klasse og dens medlemmer som følger Demeter Law-prinsippet. Jeg har nevnt kommentarer når det er aktuelt for klarhetens skyld.
offentlig klasse LawOfDemeterExample
{
// Dette er en forekomst i klassens omfang
// og dermed kan denne forekomsten nås av alle medlemmer av denne klassen
AnotherClass-forekomst = ny AnotherClass ();
offentlig ugyldig SampleMethodFollowingLoD (Test obj)
{
Gjør ingenting(); // Dette er en gyldig samtale da du ringer til en metode av samme klasse
objektdata = obj.GetData (); // Dette er også gyldig siden du ringer til en metode
// på en forekomst som er sendt som parameter
int resultat = forekomst.GetResult (); // Dette er også en gyldig samtale mens du ringer
// en metode på en forekomst lokalt opprettet
}
privat ugyldig DoNothing ()
{
// Skriv litt kode her
}
}
Her er de to andre klassene du trenger for å kompilere koden ovenfor.
offentlig klasse AnotherClass
{
offentlig int GetResult ()
{
retur -1;
}
}
offentlig klassetest
{
offentlig objekt GetData ()
{
return null;
}
}
Se nå klassen LawOfDemeterExample vist ovenfor. Koden er selvforklarende. Du kan nå lure på om Demeterloven bare gjelder metoder. Svaret er nei". Law of Demeter-prinsippet gjelder også eiendommer.
Law of Demeter Prinsippbrudd
I det første kodeeksemplet som ble forklart tidligere, startet vi diskusjonen om dette emnet ved å følge prinsippet om Demeter-loven. La oss forstå hva som skjer når vi ikke følger dette prinsippet. Tenk på dette kodeeksemplet.
var data = ny A (). GetObjectB (). GetObjectC (). GetData ();
I dette eksemplet må klienten være avhengig av klassene A, B og C. Med andre ord er det koblet til forekomster av klassene A, B og C. Hvis disse klassene i fremtiden endres, vil du komme i trøbbel som du utsetter deg for endringer som kan forekomme i noen av disse klassene i fremtiden.
