Vrlo često susrećem programere koji nisu čuli za SOLID principe (mi . — Prev.) ili objektno orijentirano programiranje (OOP), ili su čuli za njih, ali ih ne koriste u praksi. Ovaj članak opisuje prednosti OOP principa koji pomažu programeru u svakodnevnom radu. Neki od njih su dobro poznati, drugi ne toliko, pa će članak biti koristan i početnicima i iskusnim programerima.
Podsjećamo: za sve čitatelje Habra - popust od 10 000 rubalja pri upisu na bilo koji tečaj Skillbox koristeći promotivni kod Habra.
Skillbox preporučuje: Edukativni online tečaj .
Osušite (nemojte se ponavljati)
Prilično jednostavno načelo, čija je bit jasna iz naziva: "Ne ponavljajte se." Za programera to znači potrebu izbjegavanja duplikata koda, kao i mogućnost korištenja apstrakcije u svom radu.
Ako u kodu postoje dva odjeljka koji se ponavljaju, treba ih kombinirati u jednu metodu. Ako se tvrdo kodirana vrijednost koristi više od jednom, vrijedi je pretvoriti u javnu konstantu.
To je potrebno kako bi se kôd pojednostavio i olakšao održavanje, što je glavni cilj OOP-a. Ne biste trebali pretjerivati s unijom jer isti kod neće proći provjeru s OrderId-om i SSN-om.
Enkapsulacija promjena
Softverski proizvodi većine tvrtki neprestano se razvijaju. To znači da treba unijeti izmjene u kod, treba ga podržati. Možete si olakšati život korištenjem enkapsulacije. To će vam omogućiti da učinkovitije testirate i održavate svoju postojeću bazu kodova. .
Ako pišete u Javi, onda .
Princip otvoreno/zatvoreno
Ovo se načelo lako može 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 dopustiti da se promijeni njihovo ponašanje bez promjene izvornog koda.
Načelo je važno kada promjene izvornog koda zahtijevaju reviziju koda, testiranje jedinice i druge postupke. Kod koji slijedi načelo otvoreno/zatvoreno se ne mijenja kada se produži, pa s njim ima puno manje problema.
Evo primjera koda koji krši ovo načelo.
Ako trebate nešto promijeniti u njemu, trebat će vam puno vremena, jer će se morati promijeniti svi dijelovi koda koji imaju vezu sa željenim fragmentom.
Inače, otvorenost-zatvorenost jedan je od principa SOLID-a.
Načelo jedinstvene odgovornosti (SRP)
Još jedan princip iz SOLID seta. Kaže da "postoji samo jedan uzrok koji uzrokuje promjenu u klasi." Razred rješava samo jedan problem. Može imati nekoliko metoda, ali svaka se od njih koristi samo za rješavanje zajedničkog problema. Sve metode i svojstva trebaju služiti samo tome.
Vrijednost ovog načela je u tome što labavi vezu između pojedinačne softverske komponente i koda. Ako klasi dodate više od jedne funkcionalnosti, to uvodi odnos između dvije funkcije. Dakle, ako promijenite jedan od njih, velika je vjerojatnost da ćete uništiti drugi, koji je povezan s prvim. A to znači povećanje ciklusa testiranja kako bi se unaprijed identificirali svi problemi.
Načelo inverzije ovisnosti (DIP)
Gore je primjer koda u kojem AppManager ovisi o EventLogWriter-u, koji je pak usko povezan s AppManager-om. Ako trebate drugačiji način prikazivanja obavijesti, bilo da je to push, SMS ili e-pošta, trebate promijeniti klasu AppManager.
Problem se može riješiti pomoću DIP-a. Dakle, umjesto AppManager-a, zahtijevamo EventLogWriter, koji će se unijeti pomoću okvira.
DIP omogućuje jednostavnu zamjenu pojedinačnih modula s drugima mijenjanjem modula ovisnosti. To omogućuje promjenu jednog modula bez utjecaja na ostale.
Sastav umjesto nasljeđivanja
Postoje dva glavna načina ponovne upotrebe koda: nasljeđivanje i sastav, a oba imaju svoje prednosti i nedostatke. Obično se daje prednost drugom jer je fleksibilniji.
Kompozicija vam daje mogućnost mijenjanja ponašanja klase tijekom izvođenja postavljanjem njezinih svojstava. Kod implementacije sučelja koristi se polimorfizam koji daje fleksibilniju implementaciju.
Čak i Effective Java Joshue Blocha savjetuje odabir kompozicije umjesto nasljeđivanja.
Princip supstitucije Barbare Liskov (LSP)
Još jedan princip iz alata SOLID. Navodi da podtipovi moraju biti zamjenjivi za supertip. To jest, metode i funkcije koje rade s nadklasom trebale bi moći bez problema raditi s njezinim podklasama.
LSP je povezan i s načelom jedinstvene odgovornosti i s načelom podijeljene odgovornosti. Ako klasa pruža više funkcionalnosti od podklase, tada potonja neće podržavati neke od funkcionalnosti, kršeći ovo načelo.
Ovdje je dio koda koji proturječi LSP-u.
Metoda area(Rectangle r) izračunava površinu pravokutnika. Program će se srušiti nakon izvođenja Square jer ovdje Square nije pravokutnik. Prema LSP principu, funkcije koje koriste reference na osnovne klase trebale bi moći koristiti objekte izvedenih klasa bez dodatnih uputa.
Ovo načelo, koje je specifična definicija podtipa, predložila je Barbara Liskov u uvodnoj riječi konferencije 1987. pod naslovom "Apstrakcija podataka i hijerarhija", otuda i njegovo ime.
Princip razdvajanja sučelja (ISP)
Još jedan SOLID princip. Prema njemu, sučelje koje se ne koristi ne bi trebalo biti implementirano. Slijeđenje ovog načela pomaže sustavu da ostane fleksibilan i prikladan za refaktoriranje kada se naprave promjene u operativnoj logici.
Najčešće se ova situacija događa kada sučelje sadrži nekoliko funkcija odjednom, a klijent treba samo jednu od njih.
Budući da je pisanje sučelja težak zadatak, mijenjanje sučelja nakon završetka rada bez kvara bit će izazov.
Prednost ISP principa u Javi je da se sve metode prvo moraju implementirati, a tek onda se mogu koristiti po klasama. Stoga princip omogućuje smanjenje broja metoda.
Programiranje za sučelje, ne za implementaciju
Ovdje je sve jasno iz imena. Primjena ovog načela dovodi do stvaranja fleksibilnog koda koji može raditi s bilo kojom novom implementacijom sučelja.
Trebali biste koristiti vrstu sučelja za varijable, vrste povrata ili vrstu argumenta metode. Primjer je korištenje SuperClass umjesto SubClass.
To je:
Popis brojeva= getNumbers();
Ali ne:
ArrayList brojevi = getNumbers();
Ovdje je praktična provedba onoga što je gore navedeno.
Načelo delegiranja
Uobičajen primjer su metode equals() i hashCode() u Javi. Kada je potrebno usporediti dva objekta, ova akcija se delegira odgovarajućoj klasi umjesto klijentskoj.
Prednost principa je u tome što nema dupliranja koda i što je relativno jednostavno promijeniti ponašanje. Također se odnosi na delegiranje događaja.
Svi ovi principi omogućuju vam pisanje fleksibilnijeg, ljepšeg i pouzdanijeg koda s visokom kohezijom i malim spajanjem. Naravno, teorija je dobra, ali da bi programer stečeno znanje stvarno iskoristio, potrebna je praksa. Nakon što svladate načela OOP-a, vaš bi sljedeći korak mogao biti učenje uzoraka dizajna za rješavanje uobičajenih problema razvoja softvera.
Skillbox preporučuje:
- Praktični tečaj .
- Primijenjeni online tečaj .
- Dvogodišnji praktični tečaj .
Izvor: www.habr.com