Shumë shpesh takoj zhvillues që nuk kanë dëgjuar për parimet SOLID (ne . — Për.) ose për Programimin e Orientuar në Objekt (OOP), ose kanë dëgjuar, por nuk i përdorin ato në praktikë. Në këtë artikel përshkruhen avantazhet e parimeve OOP që ndihmojnë zhvilluesin në punën e tij të përditshme. Disa nga ato janë të njohura mirë, të tjerat jo shumë, kështu që artikulli do të jetë i dobishëm si për fillestarët, ashtu edhe për programuesit me përvojë.
Kujtojmë: për të gjithë lexuesit e "Habra" — zbritje prej 10,000 rubla për regjistrimin në çdo kurs Skillbox me kodin promocional "Habra".
Skillbox rekomandon: Kurs online edukativ .
DRY (Mos u përsërit vetë)
Një princip mjaft i thjeshtë, thelbi i të cilit është i qartë nga emri: "Mos u përsërit". Për programuesin kjo do të thotë nevoja për të u shmangur nga kodi i dyfishtë, si dhe mundësia për të përdorur abstraksionin në punën e tij.
Nëse në kod ka dy segmente të përsëritura, ata duhet të bashkohen në një metodë. Nëse një vlerë e caktuar përdoret më shumë se një herë, ajo duhet të kthehet në një konstantë publike.
Kjo është e nevojshme për të thjeshtuar kodin dhe për ta bërë mbështetje më të lehtë, që është objekti kryesor i OOP. Nuk duhet abuzuar me bashkimin gjithashtu, pasi i njëjti kod nuk do të kalojë verifikimin si me OrderId ashtu edhe me SSN.
Encapsulimi i ndryshimeve
Produktet softuerike të shumicës së kompanive vazhdimisht zhvillohen. Kjo do të thotë se nevojiten ndryshime në kod, ai duhet mbajtur. Mund ta lehtësoni jetën tuaj me anë të encapsulimit. Kjo do të lejojë që të testoni dhe mbani më efektivisht bazën ekzistuese të kodit. .
Nëse shkruani në Java, atëherë .
Principi i hapjes/zierjes
Ky princip mund të mbetet lehtë në mendje duke lexuar deklaratën e mëposhtme: "Entitetet softuerike (klasa, module, funksione etj.) duhet të jenë të hapura për zgjerim, por të mbyllura për ndryshim". Në praktikë, kjo do të thotë se ata mund të lejojnë të ndryshojnë sjelljen e tyre pa ndryshuar kodin burim.
Principi është i rëndësishëm, kur ndryshimet në kodin burim kërkojnë një rishikim të tij, teste modulare dhe procedura të tjera. Kodi që përgatitet sipas prinsipin e hapjes/zierjes nuk ndryshon kur zgjeron, prandaj ka shumë pak probleme me të.
Ja, ky është një shembull kodi që shkel këtë parim.
Nëse do të ketë nevojë për ndonjë ndryshim, do të duhen shumë kohë, pasi do të duhet të ndryshohen të gjitha pjesët e kodit që kanë lidhje me fragmentin e nevojshëm.
Nga ana tjetër, hapja-mbyllja është një nga parimet e SOLID.
Parimi i përgjegjësisë së vetme (SRP)
Një parim tjetër nga grupi SOLID. Ai thotë se "ka vetëm një arsye që e çon në ndryshimin e një klase". Klasa zgjidh vetëm një detyrë. Ajo mund të ketë disa metoda, por secila prej tyre përdoret vetëm për të zgjidhur detyrën e përgjithshme. Të gjitha metodat dhe pronësitë duhet të shërbejnë vetëm për këtë.
Vlera e këtij parimi është se ai lehtëson lidhjen midis komponentëve të veçantë të softuerit dhe kodit. Nëse shtoni më shumë se një funksionalitet në një klasë, kjo krijon një lidhje midis dy funksioneve. Kështu, nëse ndryshoni një prej tyre, ka mundësi të madhe të prishni tjetrën, e cila është e lidhur me të parën. Kjo do të thotë rritje të cikleve të testimit për të zbuluar të gjitha problemet paraprakisht.
Parimi i inverzimit të varësive (DIP)
Më lart është një shembull kodi, ku AppManager varet nga EventLogWriter, i cili, nga ana tjetër, është ngushtësisht i lidhur me AppManager. Nëse nevojitet një mënyrë tjetër për të treguar njoftimin, qofshin këto push, SMS ose email, duhet të ndryshohet klasa AppManager.
Problemi mund të zgjidhet duke përfshirë DIP. Pra, në vend të AppManager, ne kërkojmë EventLogWriter, i cili do të futet përmes një framework.
DIP ofron mundësinë e zëvendësimit të moduleve të veçanta me të tjera, duke ndryshuar modulun e varësisë. Kjo ofron mundësinë për të ndryshuar një modul, pa ndikuar në pjesët e tjera.
Kompozita në vend të trashëgimisë
Ka dy mënyra kryesore për të ripërdorur kodin - trashëgim dhe kompozitë, secila prej të cilave ka avantazhe dhe disavantazhe të saj. Zakonisht preferohet e dyta, pasi është më fleksibël.
Kompozita ofron mundësinë për të ndryshuar sjelljen e klasës gjatë ekzekutimit përmes caktimit të pronësive të saj. Kur implementohen ndërfaqet, përdoret polimorfizmi, i cili ofron një implementim më fleksibël.
Madje "Effective Java" e Joshua Bloch rekomandon që të preferohet kompozita përpara trashëgimisë.
Parimi i zëvendësimit të Barbara Liskov (LSP)
Një tjetër parim nga pajisjet e SOLID. Ai thotë se nënklasat duhet të jenë të zëvendësueshme për superklasën. Kështu, metodat dhe funksionet që punojnë me superklasën, duhet të kenë mundësi të punojnë pa probleme edhe me nënklasat e saj.
LSP është i lidhur si me parimin e përgjegjësisë së vetme ashtu edhe me parimin e ndarjes së përgjegjësisë. Nëse një klasë ofron më shumë funksionalitet se sa nënklasa, atëherë kjo e fundit nuk do të mbështesë disa funksione, duke shkelur këtë parim.
Ja një pjesë kodi që bie në kundërshtim me LSP.
Metoda area(Rectangle r) llogarit sipërfaqen e Rectangle. Programi do të bjerë pas ekzekutimit të Square, pasi Square këtu nuk është një Rectangle. Sipas parimit LSP, funksionet që përdorin referencia ndaj klasave themelore duhet të kenë mundësi të përdorin edhe objekte nga klasat e përftuara pa instruksione të tjera.
Ky parim, i cili do të thotë specifike për definimin e nënklasës, u propozuar nga Barbara Liskov në vitin 1987 në një konferencë në prezantimin e saj kryesor me titull "Abstraksioni e të dhënave dhe hierarkia" — prej andej erdhi edhe emri i tij.
Parimi i ndarjes së ndërfaqeve (ISP)
Një tjetër parim i SOLID. Sipas tij, një ndërfaqe që nuk përdoret nuk duhet të implementohet. Ndjekja e këtij parimi ndihmon sistemin të mbetet fleksibël dhe i përshtatshëm për ristrukturim kur bëhen ndryshime në logjikën e punës.
Kjo situatë ndodh shpesh kur ndërfaqja ka disa funksionalitete, dhe klienti ka nevojë vetëm për njërin prej tyre.
Duke qenë se shkruarja e një ndërfaqeje është një detyrë e vështirë, pas përfundimit të punës, ndryshimi i saj pa shkaktuar probleme do të jetë një sfidë.
Avantazhi i parimit ISP në Java është se së pari duhet të implementohen të gjitha metodat, dhe pastaj ato mund të përdoren nga klasat. Prandaj, parimi ofron mundësinë për të reduktuar numrin e metodave.
Programimi për ndërfaqen, jo për implementimin
Këtu gjithçka është e qartë nga emri. Zbatimi i këtij parimi çon në krijimin e kodit fleksibël, i cili do të mund të punojë me çdo implementim të ri të ndërfaqes.
Duhet të përdoret tipi i ndërfaqes për variablat, tipet e kthimit ose për tipin e argumentit të metodës. Shembulli — përdorimi i SuperClass, jo SubClass.
Pra:
List numbers= getNumbers();
Dhe jo:
ArrayList numbers = getNumbers();
Këtu është një implementim praktik i asaj që u tha më sipër.
Principi i delegimit
Një shembull i zakonshëm është metodat equals() dhe hashCode() në Java. Kur nevojitet të krahasohen dy objekte, ky veprim i delegohet klasës përkatëse në vend të klientit.
Avantazhi i këtij principi është mungesa e përsëritjes së kodit dhe ndryshimi relativisht i thjeshtë i sjelljes. Gjithashtu, ai është i aplikueshëm për delegimin e ngjarjeve.
Të gjithë këta principe lejojnë të shkruhet kod më fleksibël, më elegant dhe më të besueshëm me lidhshmëri të lartë dhe ngjitje të ulët. Sigurisht, teoria është e mirë, por që një zhvillues të fillojë të përdorë realisht njohuritë e fituara, nevojitet praktika. Hapi i ardhshëm pas përvetësimit të parimeve të OOP mund të jetë studimi i modeleve të dizajnit për të zgjidhur probleme të zakonshme në zhvillimin e softuerëve.
Skillbox rekomandon:
- Kurs praktik .
- Kurs online aplikativ .
- Kursi praktik dyvjeçar .
Burimi: habr.com
