VÕIMALIK, mis on objektorienteeritud programmeerimise 5 põhimõtet

SOLID on akronüüm, mis viitab objektorienteeritud disaini viiele põhimõttele (OOD või OOP). Need on juhised, mida arendajad saavad kasutada hõlpsasti hallatava, hooldatava ja laiendatava tarkvara loomiseks. Nende mõistete mõistmine muudab teid paremaks arendajaks ja aitab teil vältida tarkvara haldamise probleeme. Mida tähendab olla hea programmeerija?

Eeldatav lugemisaeg: 7 minutit

Igaüks, kellel on tarkvara programmeerimise kogemusi, hindab teiste kirjutatud tarkvara koodi, kasutades oma karjäärist lähtuvalt hinnanguparameetreid.

Professionaalse karjääri jooksul olen tundnud paljusid arendajaid ja olen näinud tuhandeid koodiridu ja kui pean arendaja oskusi hindama, vaatlen peamiselt kahte tegurit:

• Lihtsus koodi lugemisel;
• Kui tõenäoline on, et nende kood aja jooksul töötab ja areneb.

Õnneks on mõned põhialused või põhimõtted, mis hõlbustavad kodeerimisel paremaks saamist.

lühend SOLID tähistab:
S: ühe vastutuse põhimõte
O: avatud-suletud põhimõte
L: Liskovi asenduspõhimõte
I: Liidese eraldamise põhimõte
D: Sõltuvuste ümberpööramise põhimõte

Alustame süvenemisest esimesse SOLID põhimõttesse, nimelt

Ühe vastutuse põhimõte

Klassil (või moodulil) peaks olema ainult üks põhjus muutumiseks, arenemiseks.

Kontseptsioon ise on väga lihtne, kuid selle lihtsuse saavutamiseks võib rakendamise tee olla väga keeruline. Klassil peaks olema ainult üks põhjus muutmiseks.

Aga miks? 

Miks on nii oluline, et muutumiseks oleks ainult üks põhjus?

Näiteks kui muutmiseks on kaks erinevat põhjust, on mõeldav, et kaks erinevat meeskonda saaksid sama koodiga töötada kahel erineval põhjusel. Igaüks peab rakendama oma lahenduse, mis kompileeritud keele (näiteks C ++, C # või Java) puhul võib viia mooduliteni, mis ei ühildu teiste meeskondade või rakenduse muude osadega.

Teine näide, kui kasutate tõlgendatud keelt, peate võib-olla erinevatel põhjustel sama klassi või moodulit uuesti katsetama. See tähendab rohkem tööd, aega ja vaeva kvaliteedi kontrollimiseks.

Klassil või moodulil ühe omaduse tuvastamine peaks olema palju keerulisem kui testide käivitamiseks lihtsalt kontroll-loendi vaatamine. 

Kuid proovime mõelda vähem tehnilisest vaatenurgast, st proovime analüüsida oma klassi või mooduli kasutajat, see tähendab, kes seda kasutab. Põhiline aspekt, mida peame alati meeles pidama, on asjaolu, et meie väljatöötatud rakenduse või süsteemi kasutajad, keda konkreetne moodul teenindab, on need, kes seda modifitseerivad. Teenindajad paluvad klassi või moodulit muuta. 

Mõned näited moodulitest ja nende kasutamisest:

• Hooldusmoodul: kasutaja koosneb andmebaasi administraatoritest ja tarkvaraarhitektidest.
• Aruandlusmoodul: kasutaja koosneb kontoritöötajatest, raamatupidajatest ja tootmisest.
• Palgaarvestuse haldussüsteemi makse arvutamise moodul: kasutajate hulka võivad kuuluda juristid, juhid ja raamatupidajad.
• Raamatukogu haldussüsteemi tekstiotsingu moodul: kasutajaid võivad esindada raamatukoguhoidja või raamatukogu külastajad ja kliendid.

Nii et kui esimene samm on otsida näitlejaid või näitlejat, kellel on mooduliga vestluspartneri roll, võib kõigi rollidega inimeste seostamine olla keeruline. Väikeses ettevõttes võib üks inimene mängida mitu rolli, samas kui suures ettevõttes võib olla mitu inimest, kellel on üks roll. 

Tundub mõistlikum määratleda rollid, mitte inimesed või kasutajad.

Seetõttu:

• tarkvarasüsteemi kasutamine defiselgitab muudatuse põhjuseid;
• vastutus on funktsioonide perekond, mis rahuldab konkreetse osaleja, see tähendab süsteemi kasutaja vajadusi;
• näitlejad, muutub kasutaja funktsioonide perekonna muutuste allikaks, mis peab rahuldama kasutaja vajadused;
• kasutajate vajaduste areng, suunab funktsionaalsuse arengut;

Vaatame mõningaid näiteid

Oletame, et meil on raamatuklass, mis hõlmab raamatu kontseptsiooni ja selle funktsionaalsust.

klassi raamat {

    funktsioon getTitle () {

        tagastama "Suur raamat";

    }

    funktsioon getAuthor () {

        tagastamine “Alessandro Baricco”;

    }

    funktsiooni järgmine leht () {

        // järgmine leht

    }

    funktsioon printCurrentPage () {

        kaja “praeguse lehe sisu”;

    }

}

See on väga normaalne klass. Meil on raamat ja klass võib anda meile pealkirja, nad võivad anda meile autori ja nad saavad edasi liikuda. Lõpuks on see võimeline ka praeguse lehe ekraanile printima. 

Siiski on väike probleem. 

Mõeldes raamatuobjekti haldamisega seotud osalejatele, kes nad võiksid olla? 

Siit võime hõlpsasti mõelda kahele erinevale osalejale: Raamatute haldamine (nagu raamatukoguhoidja) Ja Andmete esitamise mehhanism (näiteks see, kuidas me tahame kasutajale sisu edastada: ekraanil kuvatav graafiline kasutajaliides, ainult teksti kasutajaliides, võib-olla printida). 

Seetõttu on meil klassiga suhtlemas kaks väga erinevat näitlejat.

Lühidalt öeldes teeb see klass segu:

• äriloogika koos 
• esitlus 

see võib olla probleem, sest see rikub ühtse vastutuse põhimõtet (SRP). 

Kuidas saaksime seda muuta, kuidas seda koodeksit parandada, et austada ühtse vastutuse põhimõtet?

Vaadake järgmist koodi:

klassi raamat {

    funktsioon getTitle () {

        tagasi “Oceano Mare”;

    }

    funktsioon getAuthor () {

        tagastamine “Alessandro Baricco”;

    }

    funktsioon pöörake lehte () {

        // järgmine leht

    }

    funktsioon getCurrentPage () {

        kaja “praeguse lehe sisu”;

    }

}

liides Printer {

    funktsioon printPage ($ leht);

}

klass StampaLibro rakendab printerit {

    funktsioon printPages ($ leht) {

        echo $ leht;

    }

}

 

klass HtmlPrinter rakendab printerit {

    funktsioon printPages ($ leht) {

        kaja ' ". $ leht. " ";

    }

}

See väga lihtne näide näitab, kuidas eraldada esitlus äriloogikast ning kooskõlas SRP-ga pakub see suuri eeliseid meie projekti paindlikkuses.

Vaatame veel ühte näidet:

Ülalolevaga sarnane näide on see, kui objekt saab end esitlusest salvestada ja sealt hankida.

klassi raamat {

    funktsioon getTitle () {

        tagasi “Oceano Mare”;

    }

    funktsioon getAuthor () {

        tagastamine “Alessandro Baricco”;

    }

    funktsioon pöörake lehte () {

        // järgmine leht

    }

    funktsioon getCurrentPage () {

        return "praeguse lehe sisu";

    }

    funktsiooni save () {

        $ filename = '/ dokumendid /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();

        file_put_contents ($ failinimi, jada ($ this));

    }

}

Nagu varemgi, võime ka siin tuvastada erinevad osalejad Raamatute haldamine (nagu raamatukoguhoidja) Ja Püsivus. Alati, kui tahame muuta lehelt lehele liikumist, peame seda klassi muutma. Meil võib muutusteks olla mitu põhjust.

klassi raamat {

    funktsioon getTitle () {

        tagasi “Oceano Mare”;

    }

    funktsioon getAuthor () {

        tagastamine “Alessandro Baricco”;

    }

    funktsioon pöörake lehte () {

        // järgmine leht

    }

    funktsioon getCurrentPage () {

        return "praeguse lehe sisu";

    }

}

klass SimpleFilePersistence {

    funktsiooni salvesta (Book $ book) {

        $ filename = '/ dokumendid /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();

        file_put_contents ($ failinimi, jada ($ book));

    }

}

Püsimisoperatsiooni teisele klassile viimine eraldab selgelt kohustused ja meil on vabadus vahetada püsivuse meetodeid, ilma et see mõjutaks meie raamatuklassi. Näiteks oleks DatabasePersistence-klassi juurutamine tühine ja meie raamatutoimingute ümber ehitatud äriloogika ei muutu.

Jätkake teise printsiibi Avatud / Suletud -> lugemist

Ercole Palmeri