Ohjelmointi

Demeterifioi Demeterin lain periaate

Demeterin laki (tai vähiten tiedon periaate) on suunnitteluohje ohjelmistosovellusten kehittämiselle. Ensimmäistä kertaa Koillis-yliopistossa vuonna 1987 käsitellyssä periaatteessa todetaan, että kohteen ei pitäisi koskaan tietää muiden esineiden sisäisiä yksityiskohtia. Se on suunniteltu edistämään löysää kytkentää ohjelmistosuunnittelussa.

Huomaa, että kytkentä voidaan määritellä ohjelmistomoduulien välisenä riippuvuustasona ja kuinka läheisesti tällaiset moduulit ovat yhteydessä toisiinsa. Mitä enemmän komponenttien välinen kytkentä on sovelluksessa, sitä vaikeampi sitä muuttaa ja ylläpitää ajan myötä. On aina hyvä käytäntö suunnitella järjestelmiä, joita on helpompi testata ja ylläpitää varmistamalla, että sovelluksen komponentit on kytketty löyhästi. Voit oppia lisää koheesiosta ja kytkemisestä artikkelistani täältä.

Demeter-lain periaatteen ymmärtäminen

Demeter-lain periaate toteaa, että moduulilla ei pitäisi olla tietoa manipuloitavien kohteiden sisäisistä yksityiskohdista. Toisin sanoen ohjelmistokomponentilla tai esineellä ei pitäisi olla tietoa muiden esineiden tai komponenttien sisäisestä toiminnasta. Ymmärretään Demeterin laki esimerkillä.

Tarkastellaan kolmea luokkaa - A, B ja C - ja näiden luokkien objekteja - vastaavasti objA, objB ja objC. Oletetaan nyt, että objA on riippuvainen objB: stä, joka puolestaan ​​muodostaa objC: n. Tässä skenaariossa objA voi vedota objB: n menetelmiin ja ominaisuuksiin, mutta ei objC: hen.

Demeter-lain periaate hyödyntää kapselointia tämän eristämisen saavuttamiseksi ja vähentää kytkentää sovelluksesi komponenttien välillä. Tämä auttaa parantamaan koodin laatua ja edistää joustavuutta ja helpottaa koodin ylläpitoa. Demeter-lain noudattamisen etuna on, että voit rakentaa ohjelmiston, joka on helposti ylläpidettävä ja mukautettavissa tuleviin muutoksiin.

Harkitse luokkaa C, jolla on menetelmä M. Oletetaan, että olet luonut luokan C ilmentymän nimeltä O. Demeterin laki määrittää, että menetelmä M voi kutsua seuraavan tyyppisiä. Tai luokan ominaisuuden tulisi kutsua seuraava tyyppi. vain jäsenille:

  • Sama esine, eli itse esine “O”
  • Objektit, jotka on välitetty argumenttina menetelmälle “M”
  • Paikalliset objektit, eli objektit, jotka on luotu menetelmän ”M” sisällä
  • Globaalit objektit, joihin pääsee olion ”O” kautta
  • Kohteen “O” suorat komponenttiobjektit

Tässä on koodiluettelo, joka kuvaa luokkaa ja sen jäseniä, jotka noudattavat Demeterin lain periaatetta. Olen maininnut kommentit missä tahansa selvyyden vuoksi.

julkisen luokan LawOfDemeterExample

    {

// Tämä on esiintymä luokan laajuudessa

// ja tästä syystä kaikki tämän luokan jäsenet voivat käyttää tätä esiintymää

AnotherClass-ilmentymä = uusi AnotherClass ();

public void SampleMethodFollowingLoD (Test obj)

        {         

Älä tee mitään(); // Tämä on kelvollinen kutsu, kun soitat saman luokan menetelmää

objektitiedot = obj.GetData (); // Tämä pätee myös, koska soitat menetelmää

// esiintymässä, joka on välitetty parametrina

int tulos = esimerkki.GetResult (); // Tämä on myös kelvollinen puhelu, kun soitat

// paikallisesti luotu ilmentymän menetelmä

        }

yksityinen mitätön DoNothing ()

        {

// Kirjoita koodi tähän

        }

    }

Tässä on kaksi muuta luokkaa, jotka sinun tarvitsee koota yllä oleva koodi.

julkinen luokka AnotherClass

    {

julkinen int GetResult ()

        {

paluu -1;

        }

    }

julkisen luokan testi

    {

julkinen esine GetData ()

        {

return null;

        }

    }

Katso nyt yllä esitetty LawOfDemeterExample-luokka. Koodi on itsestään selvä. Saatat nyt miettiä, koskeeko Demeterin lakia vain menetelmiä. Vastaus on ei". Demeter-lain periaate koskee myös kiinteistöjä.

Demeterin lain periaatteen rikkomukset

Ensimmäisessä aiemmin selitetyssä koodiesimerkissä aloitimme keskustelun tästä aiheesta noudattamalla Demeterin lain periaatetta. Ymmärretään, mitä tapahtuu, kun emme noudata tätä periaatetta. Harkitse tätä koodiesimerkkiä.

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

Tässä esimerkissä asiakkaan on oltava riippuvainen luokista A, B ja C. Toisin sanoen se on kytketty luokkien A, B ja C esiintymiin. Jos nämä luokat muuttuvat tulevaisuudessa, törmäät vaikeuksiin altistat itsesi muutoksille, joita voi tapahtua missä tahansa näistä luokista tulevaisuudessa.

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