Programmering

Afmystificering af Law of Demeter-princippet

Demeterloven (eller princippet om mindste viden) er en designretningslinje til udvikling af softwareapplikationer. Først diskuteret ved Northeastern University i 1987, siger dette princip, at et objekt aldrig skal kende de indre detaljer i andre objekter. Det blev designet til at fremme løs kobling i softwaredesign.

Bemærk, at kobling kan defineres som graden af ​​indbyrdes afhængighed, der findes mellem softwaremoduler, og hvor tæt sådanne moduler er forbundet med hinanden. Jo mere koblingen mellem komponenterne i en applikation, jo sværere bliver det at ændre og vedligeholde den over tid. Det er altid en god praksis at designe systemer, der er lettere at teste og vedligeholde ved at sikre, at komponenterne i en applikation er løst koblet. Du kan lære mere om samhørighed og kobling fra min artikel her.

Forståelse af Demeter Law-princippet

Law of Demeter-princippet siger, at et modul ikke skal have viden om de indre detaljer i de objekter, det manipulerer. Med andre ord bør en softwarekomponent eller et objekt ikke have kendskab til den interne funktion af andre objekter eller komponenter. Lad os forstå Demeter-loven med et eksempel.

Overvej tre klasser, nemlig - A, B og C - og objekter fra disse klasser - henholdsvis objA, objB og objC. Antag nu, at objA er afhængig af objB, som igen komponerer objC. I dette scenarie kan objA påberåbe sig metoder og egenskaber for objB, men ikke objC.

Law of Demeter-princippet drager fordel af indkapsling for at opnå denne isolering og reducere koblingen mellem komponenterne i din applikation. Dette hjælper med at forbedre kodekvaliteten og fremmer fleksibilitet og lettere kodevedligeholdelse. Fordelen ved at overholde Demeter-loven er, at du kan bygge software, der er let at vedligeholde og kan tilpasses til fremtidige ændringer.

Overvej en klasse C med en metode M. Antag nu, at du har oprettet en forekomst af klasse C ved navn O. Demeterloven specificerer, at metoden M kan påberåbe sig følgende typer .eller en egenskab af en klasse skal påberåbe sig følgende type kun af medlemmer:

  • Det samme objekt, dvs. selve objektet "O"
  • Objekter, der er sendt som argument til metoden “M”
  • Lokale objekter, dvs. objekter, der er oprettet inden for metoden “M”
  • Globale objekter, der er tilgængelige med objektet “O”
  • Direkte komponentobjekter af objektet “O”

Her er en kodeliste, der illustrerer en klasse og dens medlemmer, der overholder Demeter-lovprincippet. Jeg har nævnt kommentarer, hvor det er relevant for klarhed.

offentlig klasse LawOfDemeterExample

    {

// Dette er en forekomst i klassens omfang

// og derfor kan denne instans få adgang til alle medlemmer af denne klasse

AnotherClass-forekomst = ny AnotherClass ();

offentlig ugyldighed SampleMethodFollowingLoD (Test obj)

        {         

Gøre ingenting(); // Dette er et gyldigt opkald, da du kalder på en metode af samme klasse

objektdata = obj.GetData (); // Dette er også gyldigt, da du kalder en metode

// på en forekomst, der er sendt som en parameter

int resultat = instans.GetResult (); // Dette er også et gyldigt opkald, når du ringer

// en metode på en forekomst lokalt oprettet

        }

privat ugyldigt DoNothing ()

        {

// Skriv noget kode her

        }

    }

Her er de to andre klasser, som du har brug for for at kompilere ovenstående kode.

offentlig klasse AnotherClass

    {

offentlig int GetResult ()

        {

retur -1;

        }

    }

offentlig klassetest

    {

offentligt objekt GetData ()

        {

returnere null;

        }

    }

Se nu LawOfDemeterExample-klassen vist ovenfor. Koden er selvforklarende. Du spekulerer måske nu på, om Demeter-loven kun gælder for metoder. Svaret er "Nej". Law of Demeter-princippet gælder også for ejendomme.

Law of Demeter Principle overtrædelser

I det første kodeeksempel, der blev forklaret tidligere, startede vi vores diskussion om dette emne ved at overholde Princippet om Demeter-lov. Lad os forstå, hvad der sker, når vi ikke følger dette princip. Overvej dette kodeeksempel.

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

I dette eksempel bliver klienten afhængig af klasse A, B og C. Med andre ord er den koblet til forekomster af klasserne A, B og C. Hvis disse klasser i fremtiden ændres, vil du løbe ind i problemer som du udsætter dig for ændringer, der kan forekomme i nogen af ​​disse klasser i fremtiden.