Svatko s određenim iskustvom u softverskom programiranju prosuđuje softverski kod koji su napisali drugi, koristeći parametre prosudbe na osnovu svog karijernog puta.
Tijekom svoje profesionalne karijere poznavao sam mnogo programera i vidio sam hiljade redaka koda i kada moram procijeniti vještinu programera, uglavnom gledam dva faktora:
Srećom, postoje neki osnovi ili principi koji olakšavaju bolje kodiranje.
kratica SOLID označava:
S: princip jedinstvene odgovornosti
O: princip otvoreno-zatvoreno
L: Liskov princip zamjene
I: Princip segregacije sučelja
D: Princip inverzije zavisnosti
Krenimo od udubljenja u prvi ČVRSTI princip, naime
Klasa (ili modul) treba imati samo jedan razlog za promjenu, za razvoj.
Sam koncept je vrlo jednostavan, ali kako bi se postigla ta jednostavnost, put implementacije može biti vrlo kompliciran. Razred bi trebao imati samo jedan razlog za promjenu.
Ali zašto?
Zašto je toliko važno imati samo jedan razlog za promjenu?
Na primjer, ako postoje dva različita razloga za promjenu, moguće je da dva različita tima mogu raditi na istom kodu iz dva različita razloga. Svaka će morati implementirati svoje rješenje, koje bi u slučaju kompajliranog jezika (kao što je C ++, C # ili Java) moglo dovesti do modula koji nisu kompatibilni s drugim timovima ili drugim dijelovima aplikacije.
Još jedan primjer, ako koristite protumačeni jezik, možda ćete morati testirati istu klasu ili modul iz različitih razloga. To znači više rada, vremena i truda za kontrolu kvaliteta.
Prepoznavanje jedne funkcije koju bi klasa ili modul trebalo da ima mnogo je složenije od pukog pregleda kontrolne liste za pokretanje testova.
Ali pokušajmo razmišljati s manje tehničke tačke gledišta, odnosno, pokušajmo analizirati korisnika naše klase ili modula, odnosno ko će ga koristiti. Temeljni aspekt koji uvijek moramo imati na umu jest činjenica da će korisnici aplikacije ili sistema koji razvijamo, a koje opslužuje određeni modul, biti oni koji će ih zahtijevati izmjene. Oni koji budu posluženi tražit će promjenu klase ili modula.
Neki primjeri modula i njihova upotreba:
Dakle, ako je prvi korak potraga za glumcima ili glumcem koji ima ulogu sagovornika sa modulom, povezivanje pojedinaca sa svim ulogama može biti teško. U maloj kompaniji jedna osoba može igrati više uloga, dok u velikoj kompaniji može biti više ljudi koji imaju jednu ulogu.
Čini se razumnijim identificirati uloge, a ne ljude ili korisnike.
Stoga:
Pogledajmo nekoliko primjera
Pretpostavimo da imamo klasu Knjiga koja sadrži koncept knjige i njenu funkcionalnost.
class Book {
funkcija getTitle () {
povratak „Velika knjiga“;
}
funkcija getAuthor () {
povratak "Alessandro Baricco";
}
funkcija nextpage () {
// sljedeća stranica
}
funkcija printCurrentPage () {
odjek „sadržaj trenutne stranice“;
}
}
Ovo je sasvim normalna klasa. Imamo knjigu, a razred nam može dati naslov, mogu nam dati autora i mogu ići dalje. Konačno, sposoban je i za ispis trenutne stranice na ekranu.
Međutim, postoji mali problem.
Razmišljajući o akterima uključenim u upravljanje objektom Knjige, ko bi oni mogli biti?
Ovdje se lako možemo sjetiti dva različita glumca: Upravljanje knjigama (kao bibliotekar) e Mehanizam predaje podataka (poput načina na koji želimo dostaviti sadržaj korisniku: na ekranu, grafičko korisničko sučelje, samo tekstualno korisničko sučelje, možda ispis).
Stoga imamo dva vrlo različita glumca koji komuniciraju s razredom.
Ukratko, ova klasa čini kombinaciju između:
ovo može predstavljati problem jer krši načelo jedinstvene odgovornosti (SRP).
Kako se možemo promijeniti, kako možemo poboljšati ovaj kodeks tako da poštuje princip jedinstvene odgovornosti?
Pogledajte sljedeći kod:
class Book {
funkcija getTitle () {
povratak “Oceano Mare”;
}
funkcija getAuthor () {
povratak "Alessandro Baricco";
}
funkcija okreni stranicu () {
// sljedeća stranica
}
funkcija getCurrentPage () {
odjek „sadržaj trenutne stranice“;
}
}
sučelje Printer {
funkcija printPage ($ stranica);
}
klasa StampaLibro implementira Printer {
funkcija printPages ($ stranica) {
echo $ stranica;
}
}
klasa HtmlPrinter implementira Printer {
funkcija printPages ($ stranica) {
echo ' '. $ stranica. ' ';
}
}
Ovaj vrlo jednostavan primjer pokazuje kako odvojiti prezentaciju od poslovne logike, a u skladu sa SRP nudi velike prednosti u fleksibilnosti našeg projekta.
Pogledajmo još jedan primjer:
Primjer sličan onome gore je kada objekt može sačuvati i dohvatiti se iz prezentacije.
class Book {
funkcija getTitle () {
povratak “Oceano Mare”;
}
funkcija getAuthor () {
povratak "Alessandro Baricco";
}
funkcija okreni stranicu () {
// sljedeća stranica
}
funkcija getCurrentPage () {
vratiti "sadržaj trenutne stranice";
}
funkcija save () {
$ filename = '/ dokumenti /'. $ ovo-> getTitolo (). '-'. $ ovo-> getAuthor ();
file_put_contents ($ ime datoteke, serializirati ($ ovo));
}
}
Kao i ranije, i ovdje možemo prepoznati različite aktere poput Upravljanje knjigama (kao bibliotekar) e Upornost. Kad god želimo promijeniti način na koji idemo od stranice do stranice, moramo promijeniti ovu klasu. Možemo imati nekoliko razloga za promjene.
class Book {
funkcija getTitle () {
povratak “Oceano Mare”;
}
funkcija getAuthor () {
povratak "Alessandro Baricco";
}
funkcija okreni stranicu () {
// sljedeća stranica
}
funkcija getCurrentPage () {
vratiti "sadržaj trenutne stranice";
}
}
klasa SimpleFilePersistence {
function save (Book $ book) {
$ filename = '/ dokumenti /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();
file_put_contents ($ ime datoteke, serializirati ($ knjiga));
}
}
Premještanje operacije ustrajnosti u drugi razred jasno će razdvojiti odgovornosti i moći ćemo razmijeniti metode upornosti bez utjecaja na našu klasu Knjige. Na primjer, implementacija klase DatabasePersistence bila bi trivijalna i naša poslovna logika izgrađena oko operacija knjiga neće se promijeniti.
Nastavite čitajući drugi princip Otvoreno / Zatvoreno ->
Ercole Palmeri
Prošlog ponedjeljka Financial Times je objavio dogovor sa OpenAI. FT licencira svoje novinarstvo svjetske klase…
Milioni ljudi plaćaju usluge striminga, plaćajući mjesečne pretplate. Uvriježeno je mišljenje da vi…
Coveware od strane Veeam-a će nastaviti da pruža usluge odgovora na incidente u slučaju sajber iznude. Coveware će ponuditi mogućnosti forenzike i sanacije…
Prediktivno održavanje revolucionira sektor nafte i plina, s inovativnim i proaktivnim pristupom upravljanju postrojenjima.…
