Paterni strategji mundësonë që ti izolojmë algoritmet në klasa të ndryshme, dhe mundëson zëvendesimin e algoritmeve pa pasur nevojë qe kodi të ndryshohet. Pra paterni strategji na mundësonë që të shtojmë klasa të tjera që implementojnë algoritme të ndryshme por janë të tipit të njëjtë.
 

Gjithashtu kjo e mbështetë principin e parë Hapur për zgjerim e mbyllur për ndryshime. E mbështetë edhe principin e pestë në SOLID ku gjithçka varet në kontratë dhe jo në zbatim. Prandaj ky patern na mundësonë që të kemi shumë zbatime të bazuara në një kontratë.
 

Mos harroni KISS para çdo gjëje tjetër.

Shembull konkret nga jeta reale #

Nëse për shembull duam të udhëtojmë nga qyteti A në qytetin B, ne duhet ta dimë se si të arrijmë më shpejtë në destinacion. Supozojmë që ne e kemi ndërtuar një aplikacion i cili e llogaritë rrugën më të shpejtë me makinë.

Implementimi në kod do të duket si më poshtë:

Një veçori e re #

Tani na kërkohet të shtojmë një mënyrë të re transporti. Si do të shtonim një mënyrë të re transporti pa shkelur rregullat SOLID?

Një shembull se si nuk duhet të zbatohet. #

Në shembullin e mëposhtëm shohim se si rregulli i parë i principeve SOLID është thyer, Principi i një përgjegjësie. Gjithashtu thyen principin e dytë e mbyllur për ndryshime, nëse metoda e njërit prej transporteve ndryshon atëhere edhe kjo klasë duhet të ndryshojë. Kjo klasë, në jetën reale do të ishte klasa më e madhe në projekt nëse do të punonim në një aplikacion si në shembullin më lartë.

UML Modeli i strategjise #

Në diagram e shohim se e kemi një kontratë Transport, pastaj, çdo klasë me zbatime të ndryshme në bazë të kontratës. Klientit nuk i intereson sesi zbatohet algoritmi sepse ai varet në kontratë dhe kjo e mbështetë principin e pestë Inversionin i varësisë.

Implementimi korrent i dizajnit #

Pjesa me switch mund të bartet në një factory ku në bazë të inputit e krijon klasën specifike. P.SH Këtë pjesë mund ta shpjegoj kur të shkruaj për paternin Factory më në detaje.

Mbyllja #

Gjithmonë kur shkruajmë kod duhet të përpiqemi të lidhim problemin me jetën e përditshme, nëse nuk është e mundur me biznesin. Zbatimi i principeve dhe modeleve bëhet më i lehtë kur e kuptoni problemin. Për të parë nëse e kuptoni problemin atëherë provoni t’ia shpjegoni dikujt ose përdorni metodën Rubber Duck.  

Siç thotë shprehja, nëse mund t’ia shpjegoni dikujt me fjalë të thjeshta, atëherë e kuptoni problemin.

   

Rubber duck është një metodë shumë e popullarizuar që programuesit e përdorin sepse shpesh nuk kemi pyetje pasi që mendojmë se gjithçka është e qartë, ndërsa nëse përpiqemi ta shpjegojmë atë atëherë e shohim që nuk e kemi kuptuar në të vërtetë.
Në vazhdim do të postoj për modele të tjera por edhe për metoda të ndryshme që përdorin programuesit.
 

Kodim të këndshëm. <3 </>