Koha e parashikuar e leximit: 7 minuti
Kushdo me përvojë në programimin e softverit gjykon kodin e softuerit të shkruar nga të tjerët, duke përdorur parametrat e gjykimit bazuar në rrugën e tyre të karrierës.
Gjatë karrierës sime profesionale, unë kam njohur shumë zhvillues dhe kam parë mijëra rreshta të kodit dhe kur më duhet të vlerësoj aftësinë e një zhvilluesi, unë kryesisht shikoj në dy faktorë:
Për fat të mirë, ka disa baza apo parime që e bëjnë të lehtë të jesh më i mirë në kodim.
shkurtesa SOLID qëndron për:
S: parimi i përgjegjësisë së vetme
O: parimi i hapur-mbyllur
L: Parimi i zëvendësimit të Liskov
I: Parimi i ndarjes së ndërfaqes
D: Parimi i përmbysjes së varësive
Le të fillojmë duke u thelluar në parimin e parë SOLID, domethënë në
Një klasë (ose modul) duhet të ketë vetëm një arsye për të ndryshuar, për të evoluar.
Koncepti në vetvete është shumë i thjeshtë, por për të arritur këtë thjeshtësi rruga e zbatimit mund të jetë shumë e komplikuar. Një klasë duhet të ketë vetëm një arsye për të ndryshuar.
Por pse?
Pse është kaq e rëndësishme të kesh vetëm një arsye për të ndryshuar?
Për shembull, nëse ka dy arsye të ndryshme për të ndryshuar, është e mundshme që dy skuadra të ndryshme mund të punojnë në të njëjtin kod për dy arsye të ndryshme. Secili do të duhet të zbatojë zgjidhjen e tij, e cila në rastin e një gjuhe të përpiluar (të tilla si C ++, C # ose Java), mund të çojë në module që nuk janë në përputhje me skuadrat e tjera ose pjesë të tjera të aplikacionit.
Një shembull tjetër, nëse jeni duke përdorur një gjuhë të interpretuar, mund t'ju duhet të ritestoni të njëjtën klasë ose modul për arsye të ndryshme. Kjo do të thotë më shumë punë, kohë dhe përpjekje për kontrollin e cilësisë.
Identifikimi i një tipari që duhet të ketë një klasë ose modul është shumë më kompleks sesa thjesht shikimi i një liste kontrolli për të ekzekutuar testet.
Por le të përpiqemi të mendojmë nga një këndvështrim më pak teknik, domethënë, le të përpiqemi të analizojmë përdoruesin e klasës ose modulit tonë, domethënë kush do ta përdorë atë. Një aspekt themelor që duhet ta kemi gjithmonë në mendje, është fakti që përdoruesit e aplikacionit ose sistemit që ne zhvillojmë të cilët shërbehen nga një modul i veçantë do të jenë ata që kërkojnë modifikime në të. Ata që shërbehen do të kërkojnë të ndryshojnë klasën ose modulin.
Disa shembuj të moduleve dhe përdorimi i tyre:
Pra, nëse hapi i parë është kërkimi i aktorëve ose aktorit që ka rolin e bashkëbiseduesit me modulin, shoqërimi i individëve me të gjitha rolet mund të jetë i vështirë. Në një kompani të vogël, një person mund të luajë role të shumëfishta ndërsa në një kompani të madhe mund të ketë shumë njerëz që kanë një rol të vetëm.
Duket më e arsyeshme të identifikoni rolet, sesa njerëzit ose përdoruesit.
Prandaj:
Le të shohim disa shembuj
Supozoni se kemi një klasë Libri që përmbledh konceptin e një libri dhe funksionalitetin e tij.
klasa Libri {
funksioni getTitle () {
kthimi "Një libër i madh";
}
funksioni getAuthor () {
kthimi "Alessandro Baricco";
}
funksioni faqja tjetër () {
// Faqja tjetër
}
funksioni shtyp faqja aktuale () {
jehona "përmbajtja e faqes aktuale";
}
}
Kjo është një klasë shumë normale. Ne kemi një libër, dhe klasa mund të na japë titullin, ata mund të na japin autorin, dhe ata mund të vazhdojnë tutje. Më në fund, është gjithashtu në gjendje të shtypë faqen aktuale në ekran.
Sidoqoftë, ekziston një problem i vogël.
Duke menduar për aktorët e përfshirë në menaxhimin e objektit të Librit, kush mund të jenë ata?
Ne lehtë mund të mendojmë për dy aktorë të ndryshëm këtu: Menaxhimi i librit (si bibliotekar) Dhe Mekanizmi i paraqitjes së të dhënave (si p.sh. si dëshirojmë t'i dorëzojmë përmbajtje përdoruesit: në ekran, ndërfaqe grafike e përdoruesit, ndërfaqe përdoruesi vetëm me tekst, mbase e shtypur).
Prandaj kemi dy aktorë shumë të ndryshëm që bashkëveprojnë me klasën.
Me pak fjalë, kjo klasë përzihet midis:
ky mund të jetë një problem sepse shkel parimin e përgjegjësisë së vetme (SRP).
Si mund të ndryshojmë, si mund ta përmirësojmë këtë kod për të respektuar parimin e përgjegjësisë së vetme?
Shikoni kodin e mëposhtëm:
klasa Libri {
funksioni getTitle () {
kthimi "Oceano Mare";
}
funksioni getAuthor () {
kthimi "Alessandro Baricco";
}
ktheni faqen e funksionit () {
// Faqja tjetër
}
funksioni getCurrentPage () {
jehona "përmbajtja e faqes aktuale";
}
}
Printeri i ndërfaqes {
funksioni shtyp faqe ($ faqe);
}
klasa StampaLibro zbaton Printerin {
funksioni shtyp faqet ($ page) {
jehonë $ faqe;
}
}
klasa HtmlPrinter zbaton Printerin {
funksioni shtyp faqet ($ page) {
jehonë ' ' faqe $ ' ';
}
}
Ky shembull shumë i thjeshtë tregon mënyrën e ndarjes së prezantimit nga logjika e biznesit, dhe në përputhje me SRP ofron përparësi të mëdha në fleksibilitetin e projektit tonë.
Le të shohim një shembull tjetër:
Një shembull i ngjashëm me atë më sipër është kur një objekt mund të kursejë dhe të rimarrë veten nga prezantimi.
klasa Libri {
funksioni getTitle () {
kthimi "Oceano Mare";
}
funksioni getAuthor () {
kthimi "Alessandro Baricco";
}
ktheni faqen e funksionit () {
// Faqja tjetër
}
funksioni getCurrentPage () {
ktheni "përmbajtjen e faqes aktuale";
}
ruaj funksionin () {
$ filename = '/ dokumente /'. $ kjo-> getTitolo (). '-'. $ kjo-> getAuthor ();
file_put_contents ($ filename, serialize ($ this));
}
}
Si më parë, edhe këtu mund të identifikojmë aktorë të ndryshëm si Menaxhimi i librit (si bibliotekar) Dhe Këmbëngulja. Kurdoherë që duam të ndryshojmë mënyrën sesi shkojmë nga faqja në faqe, duhet ta ndryshojmë këtë klasë. Mund të kemi disa arsye për ndryshim.
klasa Libri {
funksioni getTitle () {
kthimi "Oceano Mare";
}
funksioni getAuthor () {
kthimi "Alessandro Baricco";
}
ktheni faqen e funksionit () {
// Faqja tjetër
}
funksioni getCurrentPage () {
ktheni "përmbajtjen e faqes aktuale";
}
}
klasa SimpleFilePersistence {
ruaj funksionin (Rezervo $ libër) {
$ filename = '/ dokumente /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();
file_put_contents ($ filename, serialize ($ book));
}
}
Zhvendosja e operacionit të këmbënguljes në një klasë tjetër do të ndajë qartë përgjegjësitë dhe ne do të jemi të lirë të shkëmbejmë metodat e këmbënguljes pa ndikuar në klasën tonë të Librit. Për shembull, zbatimi i një klase DatabasePersistence do të ishte i parëndësishëm, dhe logjika jonë e biznesit e ndërtuar rreth veprimeve të librit nuk do të ndryshojë.
Vazhdoni duke lexuar parimin e dytë Open / Mbyllur ->
Ercole Palmeri
Microsoft Excel është mjeti referues për analizën e të dhënave, sepse ofron shumë veçori për organizimin e grupeve të të dhënave,…
Walliance, SIM dhe platforma ndër liderët në Evropë në fushën e Crowdfunding të Pasurive të Paluajtshme që nga viti 2017, shpall përfundimin…
Filament është një kornizë e "përshpejtuar" e zhvillimit të Laravel, duke ofruar disa komponentë të plotë. Është krijuar për të thjeshtuar procesin e…
“Duhet të kthehem për të përfunduar evolucionin tim: do të projektoj veten brenda kompjuterit dhe do të bëhem energji e pastër. Pasi u vendos në…
Google DeepMind po prezanton një version të përmirësuar të modelit të tij të inteligjencës artificiale. Modeli i ri i përmirësuar ofron jo vetëm…
Laravel, i famshëm për sintaksën e tij elegante dhe veçoritë e fuqishme, gjithashtu ofron një bazë solide për arkitekturën modulare. Aty…
Cisco dhe Splunk po i ndihmojnë klientët të përshpejtojnë udhëtimin e tyre drejt Qendrës së Operacioneve të Sigurisë (SOC) të së ardhmes me…
Ransomware ka dominuar lajmet për dy vitet e fundit. Shumica e njerëzve e dinë mirë se sulmet…
