Često srećem programere koji nisu čuli za principe SOLID-a (mi . - prev.) ili objektno orijentirano programiranje (OOP), ili čuli, ali ih nemojte koristiti u praksi. Ovaj članak opisuje prednosti OOP principa koji pomažu programeru u njegovom svakodnevnom radu. Neki od njih su dobro poznati, drugi ne toliko, pa će članak biti koristan i za početnike i za već iskusne programere.
Podsećamo: za sve čitaoce "Habra" - popust od 10 rubalja pri upisu na bilo koji Skillbox kurs koristeći "Habr" promotivni kod.
Skillbox preporučuje: Obrazovni online kurs .
Osušite (nemojte se ponavljati)
Prilično jednostavan princip, čija je suština jasna iz imena: "Ne ponavljaj se". Za programera to znači potrebu za izbjegavanjem dupliranja koda, kao i mogućnost korištenja apstrakcije u radu.
Ako u kodu postoje dva odeljka koja se ponavljaju, treba ih kombinovati u jednu metodu. Ako se tvrdo kodirana vrijednost koristi više puta, vrijedi je pretvoriti u javnu konstantu.
Ovo je neophodno kako bi se kod pojednostavio i olakšao održavanje, što je glavni zadatak OOP-a. Ne biste trebali zloupotrebljavati ni sindikat, jer isti kod neće proći provjeru i sa OrderId-om i sa SSN-om.
Promijenite inkapsulaciju
Softverski proizvodi većine kompanija stalno se razvijaju. To znači da kod treba mijenjati, treba ga održavati. Inkapsulacijom možete olakšati svoj život. Ovo će vam omogućiti da efikasnije testirate i održavate postojeću bazu koda. .
Ako pišete u Javi onda .
Princip otvorenosti/zatvorenosti
Ovaj princip se može lako zapamtiti čitanjem sljedeće izjave: "Softverski entiteti (klase, moduli, funkcije, itd.) trebaju biti otvoreni za proširenje, ali zatvoreni za modifikacije." U praksi, to znači da mogu dozvoliti da se njihovo ponašanje promijeni bez promjene izvornog koda.
Princip je važan kada promjene izvornog koda zahtijevaju revizije, testiranje jedinica i druge procedure. Kod koji se pridržava principa otvoreno/zatvoreno ne mijenja se pri proširenju, tako da ima mnogo manje problema s njim.
Evo primjera koda koji krši ovaj princip.
Ako trebate nešto promijeniti u njemu, to će potrajati dosta vremena, jer ćete morati promijeniti sve dijelove koda koji imaju vezu sa željenim fragmentom.
Inače, otvorenost-zatvorenost je jedan od principa SOLID-a.
Princip jedinstvene odgovornosti (SRP)
Još jedan princip iz SOLID seta. Kaže da "postoji samo jedan razlog koji vodi do promjene klase." Razred ima samo jedan zadatak. Može imati nekoliko metoda, ali svaka od njih se koristi samo za rješavanje zajedničkog problema. Sve metode i svojstva trebaju služiti samo tome.
Vrijednost ovog principa je u tome što labavi vezu između jednog dijela softvera i koda. Dodavanje više od jedne funkcionalnosti u klasu uvodi odnos između dvije funkcije. Dakle, ako promijenite jednu od njih, velika je šansa da pokvarite drugu, vezanu za prvu. A to znači povećanje ciklusa testiranja kako bi se unaprijed identificirali svi problemi.
Princip inverzije zavisnosti (DIP)
Gore navedeni primjer koda u kojem AppManager ovisi o EventLogWriter-u, koji je zauzvrat usko povezan sa AppManager-om. Ako vam je potreban drugačiji način za prikazivanje obavještenja, bilo da je to push, SMS ili email, morate promijeniti klasu AppManager.
Problem se može riješiti pomoću DIP-a. Dakle, umjesto AppManager-a, tražimo EventLogWriter, koji će biti ubrizgan pomoću okvira.
DIP omogućava jednostavnu zamjenu pojedinačnih modula drugim promjenom modula ovisnosti. Ovo omogućava promjenu jednog modula bez utjecaja na ostale.
Sastav umjesto nasljeđivanja
Dva glavna načina ponovnog korištenja koda su nasljeđivanje i sastav, svaki sa svojim prednostima i nedostacima. Drugi se obično preferira jer je fleksibilniji.
Kompozicija vam daje mogućnost da promijenite ponašanje klase u vrijeme izvođenja postavljanjem njenih svojstava. Prilikom implementacije interfejsa koristi se polimorfizam, što daje fleksibilniju implementaciju.
Čak i "efikasna Java" Joshua Bloch savjetuje da se preferira kompozicija umjesto nasljeđivanja.
Barbara Liskov Princip supstitucije (LSP)
Još jedan princip iz SOLID kompleta alata. Navodi da podtipovi moraju biti zamjenjivi za supertip. To jest, metode i funkcije koje rade sa superklasom treba da budu u stanju da rade bez problema sa njenim podklasama.
LSP je povezan i sa principom jedinstvene odgovornosti i principom razdvajanja odgovornosti. Ako klasa pruža više funkcionalnosti od potklase, onda potonja neće podržavati neku funkcionalnost, kršeći ovaj princip.
Evo dijela koda koji je u suprotnosti sa LSP-om.
Metoda area(Rectangle r) izračunava površinu pravougaonika. Program će se srušiti nakon izvršavanja Squarea, pošto Square ovdje nije pravougaonik. Prema LSP principu, funkcije koje koriste reference na osnovne klase trebale bi biti u mogućnosti da koriste objekte izvedenih klasa bez dodatnih instrukcija.
Ovaj princip, koji je specifična definicija podtipa, predložila je Barbara Liskov na konferenciji 1987. godine pod nazivom "Apstrakcija i hijerarhija podataka" - otuda i njegovo ime.
Princip razdvajanja interfejsa (ISP)
Još jedan SOLID princip. Prema njegovim riječima, ne treba implementirati interfejs koji se ne koristi. Praćenje ovog principa pomaže sistemu da ostane fleksibilan i refaktorski pri unošenju promjena u logiku rada.
Najčešće se ova situacija događa kada sučelje sadrži nekoliko funkcionalnosti odjednom, a klijentu je potrebna samo jedna od njih.
Pošto je pisanje interfejsa složen zadatak, nakon što se posao završi, promena bez ikakvog kvara biće problem.
Prednost ISP principa u Javi je da se sve metode prvo moraju implementirati, a tek onda ih klase mogu koristiti. Stoga princip omogućava smanjenje broja metoda.
Programiranje za interfejs, a ne implementacija
Ovdje je sve jasno iz imena. Primjena ovog principa dovodi do fleksibilnog koda koji može raditi sa bilo kojom novom implementacijom interfejsa.
Trebali biste koristiti tip interfejsa za varijable, tipove povrata ili tip argumenta metode. Primjer je korištenje SuperClass umjesto SubClass.
To je:
Brojevi liste= getNumbers();
Ali ne:
ArrayList numbers = getNumbers();
Evo praktične implementacije onoga što je gore rečeno.
Princip delegiranja
Uobičajeni primjer su metode equals() i hashCode() u Javi. Kada treba uporediti dva objekta, ova akcija se delegira odgovarajućoj klasi umjesto klasi klijenta.
Prednost principa je u tome što nema dupliciranja koda i relativno je lako promijeniti ponašanje. To se također odnosi na delegiranje događaja.
Svi ovi principi vam omogućavaju da napišete fleksibilniji, ljepši i pouzdaniji kod s visokom kohezijom i niskom spregom. Naravno, teorija je dobra, ali da bi programer zaista počeo da koristi stečeno znanje, potrebna je praksa. Sljedeći korak nakon savladavanja principa OOP-a može biti proučavanje obrazaca dizajna za rješavanje uobičajenih problema razvoja softvera.
Skillbox preporučuje:
- Praktični kurs .
- Primijenjeni online kurs .
- Dvogodišnji praktični kurs .
izvor: www.habr.com