Shumë shpesh takoj zhvillues që nuk kanë dëgjuar për parimet SOLID (ne . — Përkth.) ose programim i orientuar nga objekti (OOP), ose keni dëgjuar për to, por mos i përdorni në praktikë. Ky artikull përshkruan përfitimet e parimeve OOP që ndihmojnë zhvilluesin në punën e tij të përditshme. Disa prej tyre janë të njohura, të tjerët jo aq 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 Habr - një zbritje prej 10 rubla kur regjistroheni në çdo kurs Skillbox duke përdorur kodin promovues Habr.
Skillbox rekomandon: Kurs edukativ online .
THATA (Mos e përsëritni veten)
Një parim mjaft i thjeshtë, thelbi i të cilit është i qartë nga emri: "Mos e përsërit veten". Për një programues, kjo do të thotë nevojën për të shmangur kodin e kopjuar, si dhe mundësinë për të përdorur abstraksionin në punën e tyre.
Nëse kodi ka dy seksione të përsëritura, ato duhet të kombinohen në një metodë. Nëse një vlerë e koduar përdoret më shumë se një herë, ia vlen ta konvertoni atë në një konstante publike.
Kjo është e nevojshme për të thjeshtuar kodin dhe për ta bërë më të lehtë mirëmbajtjen, që është qëllimi kryesor i OOP. Ju gjithashtu nuk duhet ta përdorni bashkimin, pasi i njëjti kod nuk do të kalojë verifikimin si me OrderId ashtu edhe me SSN.
Ndryshimet përmbledhëse
Shumica e produkteve softuerike të kompanive po evoluojnë vazhdimisht. Kjo do të thotë që duhet të bëhen ndryshime në kod, ai duhet të mbështetet. Ju mund ta bëni jetën tuaj më të lehtë duke përdorur kapsulimin. Kjo do t'ju lejojë të testoni dhe mbani në mënyrë më efikase bazën tuaj ekzistuese të kodit. .
Nëse shkruani në Java, atëherë .
Parimi i hapur/mbyllur
Ky parim mund të mbahet mend lehtësisht duke lexuar deklaratën e mëposhtme: "Entitetet e softuerit (klasat, modulet, funksionet, etj.) duhet të jenë të hapura për zgjerim, por të mbyllura për modifikim." Në praktikë, kjo do të thotë se ata mund të lejojnë ndryshimin e sjelljes së tyre pa ndryshuar kodin burimor.
Parimi është i rëndësishëm kur ndryshimet në kodin burim kërkojnë rishikim të kodit, testim të njësisë dhe procedura të tjera. Kodi që ndjek parimin e hapur/mbyllur nuk ndryshon kur zgjerohet, kështu që ka shumë më pak probleme me të.
Këtu është një shembull i kodit që shkel këtë parim.
Nëse keni nevojë të ndryshoni diçka në të, do të duhet shumë kohë, pasi të gjitha seksionet e kodit që kanë një lidhje me fragmentin e dëshiruar do të duhet të ndryshohen.
Nga rruga, hapja-mbyllja është një nga parimet e SOLID.
Parimi i Përgjegjësisë së Vetëm (SRP)
Një tjetër parim nga grupi SOLID. Ai thotë se "ka vetëm një shkak që shkakton një ndryshim në klasë". Klasa zgjidh vetëm një problem. Mund të ketë disa metoda, por secila prej tyre përdoret vetëm për të zgjidhur një problem të përbashkët. Të gjitha metodat dhe vetitë duhet t'i shërbejnë vetëm kësaj.
Vlera e këtij parimi është se ai liron lidhjen midis komponentit individual të softuerit dhe kodit. Nëse shtoni më shumë se një funksionalitet në një klasë, ai prezanton një marrëdhënie midis dy funksioneve. Kështu, nëse ndërroni njërën prej tyre, ka shumë mundësi të prishni të dytin, i cili është i lidhur me të parën. Dhe kjo nënkupton rritjen e cikleve të testimit në mënyrë që të identifikohen të gjitha problemet paraprakisht.
Parimi i përmbysjes së varësisë (DIP)
Më sipër është një shembull kodi ku AppManager varet nga EventLogWriter, i cili nga ana tjetër është i lidhur ngushtë me AppManager. Nëse keni nevojë për një mënyrë tjetër për të shfaqur një njoftim, qoftë push, SMS apo email, duhet të ndryshoni klasën AppManager.
Problemi mund të zgjidhet duke përdorur DIP. Pra, në vend të AppManager, ne kërkojmë një EventLogWriter, i cili do të futet duke përdorur kornizën.
DIP bën të mundur zëvendësimin e lehtë të moduleve individuale me të tjera duke ndryshuar modulin e varësisë. Kjo bën të mundur ndryshimin e një moduli pa ndikuar tek të tjerët.
Përbërja në vend të trashëgimisë
Ekzistojnë dy mënyra kryesore për të ripërdorur kodin: trashëgimia dhe kompozimi, të cilat të dyja kanë avantazhet dhe disavantazhet e tyre. Zakonisht preferohet i dyti sepse është më fleksibël.
Përbërja ju jep mundësinë për të ndryshuar sjelljen e një klase në kohën e ekzekutimit duke vendosur vetitë e saj. Gjatë zbatimit të ndërfaqeve, përdoret polimorfizmi, i cili jep një zbatim më fleksibël.
Edhe Effective Java nga Joshua Bloch këshillon zgjedhjen e përbërjes në vend të trashëgimisë.
Parimi i zëvendësimit të Barbara Liskov (LSP)
Një tjetër parim nga paketa e veglave SOLID. Ai thotë se nëntipet duhet të jenë të zëvendësueshme për supertipin. Kjo do të thotë, metodat dhe funksionet që punojnë me një superklasë duhet të jenë në gjendje të funksionojnë pa probleme me nënklasat e saj.
LSP është i lidhur si me parimin e përgjegjësisë së vetme ashtu edhe me parimin e përgjegjësisë së përbashkët. Nëse një klasë ofron më shumë funksionalitet se një nënklasë, atëherë kjo e fundit nuk do të mbështesë disa nga funksionet, duke shkelur këtë parim.
Këtu është një pjesë e kodit që kundërshton LSP.
Metoda e zonës (Rectangle r) llogarit sipërfaqen e një drejtkëndëshi. Programi do të prishet pas ekzekutimit të Sheshit sepse Sheshi nuk është një Drejtkëndësh këtu. Sipas parimit LSP, funksionet që përdorin referenca për klasat bazë duhet të jenë në gjendje të përdorin objekte të klasave të derivuara pa udhëzime shtesë.
Ky parim, i cili është një përkufizim specifik i një nëntipi, u propozua nga Barbara Liskov në një konferencë kryesore të vitit 1987 me titull "Abstraksioni i të dhënave dhe hierarkia", prej nga vjen emri i tij.
Parimi i ndarjes së ndërfaqes (ISP)
Një tjetër parim SOLID. Sipas tij, një ndërfaqe që nuk përdoret nuk duhet të zbatohet. Ndjekja e këtij parimi ndihmon sistemin të mbetet fleksibël dhe i përshtatshëm për rifaktorim kur bëhen ndryshime në logjikën e funksionimit.
Më shpesh, kjo situatë ndodh kur ndërfaqja përmban disa funksione në të njëjtën kohë, dhe klientit i duhet vetëm një prej tyre.
Meqenëse shkrimi i një ndërfaqeje është një detyrë e vështirë, ndryshimi i tij pasi të përfundojë puna pa prishur asgjë do të jetë një sfidë.
Avantazhi i parimit të ISP në Java është se të gjitha metodat duhet të zbatohen fillimisht, dhe vetëm atëherë ato mund të përdoren nga klasa. Prandaj, parimi bën të mundur zvogëlimin e numrit të metodave.
Programimi për ndërfaqen, jo për zbatimin
Gjithçka këtu është e qartë nga emri. Zbatimi i këtij parimi çon në krijimin e një kodi fleksibël që mund të funksionojë me çdo implementim të ri të ndërfaqes.
Ju duhet të përdorni llojin e ndërfaqes për variablat, llojet e kthimit ose llojin e argumentit të metodës. Një shembull është përdorimi i SuperClass në vend të Nënklasës.
Kjo eshte:
Lista e numrave= getNumbers();
Por jo:
Numrat ArrayList = getNumbers();
Këtu është një zbatim praktik i asaj që u diskutua më lart.
Parimi i delegimit
Një shembull i zakonshëm janë metodat e barabartë () dhe hashCode () në Java. Kur është e nevojshme të krahasohen dy objekte, ky veprim delegohet në klasën përkatëse në vend të asaj të klientit.
Avantazhi i parimit është se nuk ka dyfishim të kodit dhe është relativisht e thjeshtë për të ndryshuar sjelljen. Kjo vlen edhe për delegimin e ngjarjeve.
Të gjitha këto parime ju lejojnë të shkruani kode më fleksibël, më të bukur dhe të besueshëm me kohezion të lartë dhe bashkim të ulët. Sigurisht, teoria është e mirë, por që një zhvillues të përdorë njohuritë e fituara, duhet praktikë. Pasi të keni zotëruar parimet OOP, hapi juaj i ardhshëm mund të jetë të mësoni modelet e projektimit për të zgjidhur problemet e zakonshme të zhvillimit të softuerit.
Skillbox rekomandon:
- Kurse praktike .
- Aplikuar kursin online .
- Kurse praktike dyvjeçare .
Burimi: www.habr.com