Vaje

TRDO, kakšnih je 5 načel objektno usmerjenega programiranja

SOLID je kratica, ki se nanaša na pet načel objektno usmerjenega oblikovanja (OOD ali OOP). To so smernice, s katerimi lahko razvijalci ustvarijo programsko opremo, ki jo je enostavno upravljati, vzdrževati in razširjati. Če boste razumeli te koncepte, boste postali boljši razvijalec in se boste izognili težavam pri upravljanju programske opreme. Kaj pomeni biti dober programer?

Kdor ima nekaj izkušenj s programiranjem programske opreme, presoja programsko kodo, ki so jo napisali drugi, z uporabo presojnih parametrov glede na svojo poklicno pot.

V svoji poklicni karieri sem poznal veliko razvijalcev in videl sem na tisoče vrstic kode. Ko moram oceniti znanje razvijalca, pogledam predvsem dva dejavnika:

  • Preprostost branja kode;
  • Kako verjetno je, da bo njihova koda delovala in se sčasoma razvijala.

Na srečo obstaja nekaj osnov ali načel, ki olajšajo boljše kodiranje.

kratica SOLID pomeni:
S: načelo enotne odgovornosti
O: načelo odprto-zaprto
L: Liskovo načelo zamenjave
I: Načelo ločevanja vmesnikov
D: Načelo inverzije odvisnosti

Začnimo s poglabljanjem v prvo TRDO načelo, in sicer

Načelo enotne odgovornosti

Razred (ali modul) bi moral imeti samo en razlog za spremembo, za razvoj.

Koncept sam je zelo preprost, vendar je za dosego te preprostosti izvedbena pot lahko zelo zapletena. Razred bi moral imeti samo en razlog za spremembo.

Ampak zakaj? 

Zakaj je tako pomembno, da imamo samo en razlog za spremembo?

Če sta na primer dva različna razloga za spremembo, je mogoče, da bi lahko dve različni skupini delali na isti kodi iz dveh različnih razlogov. Vsak bo moral implementirati svojo rešitev, ki bi v primeru prevedenega jezika (na primer C ++, C # ali Java) lahko privedla do modulov, ki niso združljivi z drugimi skupinami ali drugimi deli aplikacije.

Drug primer: če uporabljate tolmačeni jezik, boste morda morali iz istega razloga preizkusiti isti razred ali modul. To pomeni več dela, časa in truda za nadzor kakovosti.

Ugotavljanje edine funkcije, ki bi jo moral imeti razred ali modul, je veliko bolj zapleteno kot preprosto pregledovanje kontrolnega seznama za izvajanje testov. 

Toda poskusimo razmišljati z manj tehničnega vidika, torej poskusimo analizirati uporabnika našega razreda ali modula, to je, kdo ga bo uporabil. Temeljni vidik, ki ga moramo vedno imeti v mislih, je dejstvo, da bodo uporabniki aplikacije ali sistema, ki ga razvijamo in jih oskrbuje določen modul, tisti, ki bodo zahtevali njegove spremembe. Uslužbenci bodo prosili za spremembo razreda ali modula. 

Nekaj ​​primerov modulov in njihove uporabe:

  • Vzdrževalni modul: uporabnika sestavljajo skrbniki baz podatkov in arhitekti programske opreme.
  • Modul poročanja: uporabnika sestavljajo pisarniški delavci, računovodje in proizvodnja.
  • Modul za izračun plačil za sistem upravljanja plač: uporabniki lahko vključujejo odvetnike, menedžerje in računovodje.
  • Modul za iskanje besedila za sistem upravljanja knjižnice: uporabnika lahko zastopa knjižničar ali obiskovalci in kupci same knjižnice.

Če je torej prvi korak iskanje igralcev ali igralca, ki ima vlogo modula, je povezovanje posameznikov z vsemi vlogami težko. V majhnem podjetju lahko ena oseba igra več vlog, medtem ko je v velikem podjetju več ljudi, ki imajo eno vlogo. 

Zdi se bolj smiselno opredeliti vloge kot pa ljudi ali uporabnike.

Zato:

  • uporabo programskega sistema defipojasni razloge za spremembo;
  • odgovornost je družina funkcij, ki zadovolji potrebe določenega akterja, torej uporabnika sistema;
  • akterji postane uporabnik vir sprememb za družino funkcionalnosti, ki morajo zadovoljiti potrebe uporabnika;
  • razvoj potreb uporabnikov, vodi razvoj funkcionalnosti;

Poglejmo nekaj primerov

Recimo, da imamo razred Book, ki vsebuje koncept knjige in njeno funkcionalnost.

razred Knjiga {

    funkcija getTitle () {

        vrnitev "Velika knjiga";

    }

    funkcija getAuthor () {

        vrnitev "Alessandro Baricco";

    }

    funkcija naslednja stran () {

        // Naslednja stran

    }

    funkcija printCurrentPage () {

        odmev »vsebina trenutne strani«;

    }

}

To je zelo običajen razred. Imamo knjigo in razred nam lahko da naslov, lahko nam avtorja in gre lahko naprej. Končno lahko tudi natisne trenutno stran na zaslon. 

Vendar pa obstaja majhen problem. 

Ko razmišljate o akterjih, ki sodelujejo pri upravljanju predmeta Knjiga, kdo bi lahko bili? 

Tu lahko zlahka pomislimo na dva različna igralca: Upravljanje knjig (kot knjižničarka) In Mehanizem predložitve podatkov (na primer, kako želimo uporabniku dostaviti vsebino: na zaslonu, grafični uporabniški vmesnik, samo besedilni uporabniški vmesnik, morda tiskanje). 

V razredu imamo torej dva zelo različna igralca.

Na kratko je ta razred mešanica med:

  • poslovna logika s 
  • predstavitev 

to je lahko problem, ker krši načelo enotne odgovornosti (SRP). 

Kako se lahko spremenimo, kako lahko izboljšamo ta kodeks, da bo spoštoval načelo enotne odgovornosti?

Oglejte si naslednjo kodo:

razred Knjiga {

    funkcija getTitle () {

        povratek “Oceano Mare”;

    }

    funkcija getAuthor () {

        vrnitev "Alessandro Baricco";

    }

    funkcija obrni stran () {

        // Naslednja stran

    }

    funkcija getCurrentPage () {

        odmev »vsebina trenutne strani«;

    }

}

vmesnik tiskalnik {

    funkcija printPage ($ stran);

Glasilo o inovacijah
Ne zamudite najpomembnejših novic o inovacijah. Prijavite se, če jih želite prejemati po e-pošti.

}

razred StampaLibro izvaja tiskalnik {

    funkcija printPages ($ stran) {

        echo $ stran;

    }

}

 

razred HtmlPrinter izvaja tiskalnik {

    funkcija printPages ($ stran) {

        odmev ". $ strani. " ';

    }

}

Ta zelo preprost primer prikazuje, kako ločiti predstavitev od poslovne logike in v skladu s SRP ponuja velike prednosti v prilagodljivosti našega projekta.

Poglejmo si še en primer:

Primer, podoben zgornjemu, je, ko se objekt lahko shrani in prikliče iz predstavitve.

razred Knjiga {

    funkcija getTitle () {

        povratek “Oceano Mare”;

    }

    funkcija getAuthor () {

        vrnitev "Alessandro Baricco";

    }

    funkcija obrni stran () {

        // Naslednja stran

    }

    funkcija getCurrentPage () {

        vrni "vsebina trenutne strani";

    }

    funkcija save () {

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

        file_put_contents ($ ime datoteke, serializiraj ($ to));

    }

}

Kot prej smo tudi tu lahko prepoznali različne akterje, kot so Upravljanje knjig (kot knjižničarka) In Vztrajnost. Kadar koli želimo spremeniti način, kako gremo od strani do strani, moramo spremeniti ta razred. Razlogov za spremembe imamo lahko več.

razred Knjiga {

    funkcija getTitle () {

        povratek “Oceano Mare”;

    }

    funkcija getAuthor () {

        vrnitev "Alessandro Baricco";

    }

    funkcija obrni stran () {

        // Naslednja stran

    }

    funkcija getCurrentPage () {

        vrni "vsebina trenutne strani";

    }

}

razred SimpleFilePersistence {

    function save (Book $ book) {

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

        file_put_contents ($ ime datoteke, serializiraj ($ knjiga));

    }

}

Premik operacije vztrajanja v drug razred bo jasno ločil odgovornosti in lahko si bomo izmenjali metode vztrajnosti, ne da bi to vplivalo na naš razred Knjige. Na primer, uvajanje razreda DatabasePersistence bi bilo nepomembno in naša poslovna logika, zgrajena okoli knjižnih operacij, se ne bo spremenila.

Nadaljujte z branjem drugega načela Odprto / Zaprto ->

Ercole Palmeri

Glasilo o inovacijah
Ne zamudite najpomembnejših novic o inovacijah. Prijavite se, če jih želite prejemati po e-pošti.

Nedavni članki

Prednosti pobarvank za otroke - svet čarovnije za vse starosti

Razvijanje finih motoričnih spretnosti z barvanjem otroke pripravi na kompleksnejše spretnosti, kot je pisanje. Za barvanje…

2 maja 2024

Prihodnost je tukaj: Kako ladjarska industrija revolucionira svetovno gospodarstvo

Pomorski sektor je prava svetovna gospodarska sila, ki je krmarila proti 150 milijardnemu trgu...

1 maja 2024

Založniki in OpenAI podpisujejo sporazume za urejanje pretoka informacij, ki jih obdeluje umetna inteligenca

Prejšnji ponedeljek je Financial Times objavil dogovor z OpenAI. FT licencira svoje vrhunsko novinarstvo ...

April 30 2024

Spletna plačila: Evo, kako vam storitve pretakanja omogočajo večno plačevanje

Milijoni ljudi plačujejo storitve pretakanja in plačujejo mesečne naročnine. Splošno mnenje je, da si…

April 29 2024