Atklāts dizaina modelis: stratēģijas modelis



Šajā emuārā mēs atklāsim stratēģijas dizaina modeli, kas tiek izmantots, lai izveidotu savstarpēji aizvietojamu algoritmu saimi, ko var izvēlēties dinamiski.

'

Laipni lūdzam sērijas “Design Patterns Exposed” pirmajā ierakstā. Šajā sērijā mēs katru dizaina modeli atklāsim no nulles.





Vienkārši zinot programmēšanas valodu un tās konstrukcijas, jūs nepadarīsit labāku programmētāju vai izstrādātāju. Tas prasa zināšanas par dizaina modeļiem, lai izveidotu programmatūru, kas darbosies šodien un arī nākotnē.

Daudzi izstrādātāji jau ir saskārušies ar tām dizaina problēmām, ar kurām jūs tagad saskaraties vai saskarsieties nākotnē. Viņi ir norādījuši standarta veidu, kā tikt galā ar šo problēmu. Tātad, izmantojot dizaina modeļus, jūs saņemat priekšrocības, izmantojot pārbaudītas metodes.



Katrs dizaina modelis ir paredzēts konkrēta veida situāciju risināšanai, iespējams, ir situācijas, kad var izmantot vairākus dizaina modeļus.

Lielākā daļa programmētāju vienkārši mēģina atrisināt problēmu, ar kuru viņi saskaras, neuztraucoties par dizaina modeļiem, lieku kodu vai pat saspringtu savienošanu. Bet labi programmētāji sāk citādi. Viņi domā par mūsdienu prasībām, nākotnes prasībām, koda uzturēšanu un koda atkārtotu lietošanu.

Labi programmētāji nesteidzas sākt kodēt, tiklīdz viņi būs saņēmuši prasības. Viņi sēž un domā par problēmu, vai viņu dizains darbosies. Ja jā, vai tas darbosies pēc 6 mēnešiem, kad prasības mainīsies.



Labi programmētāji paņem savu pildspalvu un papīru un sāk veidot savas klases un attiecības starp klasēm. Viņi cenšas panākt brīvu savienojumu un augstu saliedētību, vienlaikus darot visu, kas viņu prātā ir uz objektu orientēti principi. Viņi uzreiz neiet zemā līmeņa kodā. Lai izstrādātu elastīgu un atkārtoti lietojamu programmatūru, jums jāievēro šī pieeja, pretējā gadījumā jūs vienmēr atradīsit modificējošu kodu, kuru esat uzrakstījis iepriekš.

Ir tikai viena lieta, kas programmatūras nozarē ir nemainīga, un tas ir Mainīt. Prasības noteikti mainīsies. Tātad, kā mēs izstrādājam programmatūru, kuru jūsu kods var viegli pielāgot nākotnes prasībām? Lai to sāktu, jums tas jāsāk agri un jāveido tā, lai turpmākās prasības nesabojātu jūsu iepriekšējo kodu.

Kā es to varu izdarīt?

Nu, to var izdarīt, ievērojot uz šiem principiem balstītos dizaina principus un dizaina modeļus.

Tagad ienirsim kodēšanā un sāksim ceļu, lai kļūtu par labāku programmētāju. Šajā amatā mēs atklāsim vienu no vissvarīgākajiem modeļiem - stratēģijas modelis .

Kad es saku vissvarīgāko, tas atspoguļo kopējo problēmu, kuru atrisina stratēģijas modelis.

Kas ir stratēģijas modelis?

Šeit ir definīcija tieši no grāmatas “Četru banda”: ​​“Stratēģijas modeli izmanto, lai izveidotu maināmu algoritmu saimi, no kuras izpildes laikā tiek izvēlēts nepieciešamais process”.

Gadījumā, ja jūs esatnespēj saprast, neuztraucieties, mēs to izskaidrosim avienkāršākveidālai jūssaprast.

Vispirms sapratīsim problēmu un tad redzēsim, kā stratēģijas modelis to var atrisināt.

Iepriekš minētajā UML diagrammā mums ir Dzīvnieku abstraktā klase un divas konkrētas klases - Suns un Putns, kas sniedzas no Dzīvnieku super klases.

Tātad definēsim dzīvnieku abstrakto klasi un divas konkrētās klases - suni un putnus.

Ko jūs domājat par iepriekš minēto dizainu? Mūsu dizainā ir viena liela kļūda.

Visi dzīvnieki nevar lidot, tāpat kā iepriekš minētajā gadījumā suns nevar lidot. Bet tomēr tam ir “lidot” uzvedība.

Mēs pieļāvām kļūdu, dzīvnieku klasē ierakstot abstraktās mušas () metodi. Šis dizains piespiedīs katru apakšklasi Suns, Putns, Pingvīns, Krokodils, Zoss utt. Ieviest fly () metodi.

Mums vajadzēja saprast, ka lidošana ir spēja, kas nebūs visiem dzīvniekiem. Nodrošinot fly () metodi Animal abstraktajā klasē, mēs esam iestatījuši lidošanas spējas visās apakškategorijās, kas nav pareizi visām dzīvnieku apakškategorijām.

Jūs varētu domāt, kāda ir problēma, ieviešot mušas metodi apakšklasēs. Lai gan jūs varat ieviest fly () metodi lidojošo dzīvnieku apakšklasēs, lai vienkārši drukātu “Es nevaru lidot”. Bet problēma ir tāda, ka jūs joprojām piešķirat mušu uzvedību nelidojošajiem dzīvniekiem. Tas nav pareizi.

Kāda ir sajūta, ja izsaucat suni.fly () vai krokodilu.fly ().

Tātad, tagad mēs esam sapratuši, ka mūsu dizains nav pareizs, un mums vajadzētu noņemt fly () metodi no Animal apakšklases.

Kāds ir cits veids, kā veidot mūsu klases tā, lai mūsu dizains nepiespiestu visas dzīvnieku apakšklases izturēties pret mušām.

Viens risinājums, kas uzreiz nāk prātā, ir tas, ka mēs varam izveidot lidojošo saskarni, izmantojot lidojuma metodi, un tikai dzīvnieki, kuri var lidot, īstenos šo lidojuma saskarni. Tādā veidā mēs nepiespiedīsim visas Dzīvnieku apakšklases, lai noteiktu mušu uzvedību. Tāpēc kodēsim šo dizaina pieeju.

Tagad mūsu Dzīvnieku klase pēc mušu metodes noņemšanas no Dzīvnieku klases izskatīsies kā zemāk redzamais kods.

Tagad definēsim Flying interfeisu

Tagad suņu klase tiks mainītazemāk redzamo kodu, un tam nav jābūt ar mušu uzvedību.

Apskatīsim dažas no mūsu Dzīvnieku apakšklasēm, kurām būs lidojuma uzvedība.

pirmā meklēšanas algoritma pseidokods

Mēs esam atrisinājuši savu iepriekšējo problēmu, bet mēs nonācām jaunās nepatikšanās un tā ir “Kodu dublēšanās”.

Sakiet, mums būs 100 dažādas lidojošo dzīvnieku apakšklases. Mums ir jākopē mušu uzvedības kods, jo lidošanas saskarne nevar nodrošināt nekādu mušu uzvedības ieviešanu, un vēlāk, ja mēs vēlamies mainīt fly () metodes ieviešanu jebkurā apakšklasē, mums būs jāatver šī klase un jāmaina kods kas ir slikti. Mums trūkst kaut kas liels, un tas ir, mēs nevaram mainīt klases lidošanas uzvedību izpildes laikā.

Bet neuztraucieties, jo stratēģijas modelis ir paredzēts, lai jūs izkļūtu no šīs problēmas.

Tāpēc pārlabosim mūsu kodu, lai izmantotu stratēģijas modeli.

kas ir apakšvirkne java

Lidojošais interfeiss paliks tāds pats kā tagad. Tā vietā, lai katra lidojošā apakšklase ieviestu pašu lidojuma saskarni, mēs definēsim atsevišķas konkrētas klases, kas īstenos atšķirīgu lidošanas uzvedību. Apskatīsim, kā to izdarīt.

Tātad, kā tas viss darbojas, apskatīsim TestClass

Izmantojot stratēģijas modeli, mēs tagad varam mainīt jebkura dzīvnieka lidošanas uzvedību laikā, tas ir, nepiespiežot nevienu apakšklasi, lai norādītu pašu lidošanas uzvedību.

Kad izmantot stratēģijas modeli?

Kad vēlaties dinamiski mainīt uzvedību izpildes laikā.

Lai pārliecinātos, ka skaidri saprotat stratēģijas modeli, ņemsim citu piemēru.

Iepriekš minētajā darbinieku klasē darbiniekam nosaka atalgojumu atkarībā no viņa / viņas amata. Ja darbinieks ir praktikants, pamatalgā tiek pievienota 10% prēmija, lai aprēķinātu faktisko atalgojumu.

Ja darbinieks ir “tīmekļa izstrādātājs”, pamatalgā tiek pievienota 20% prēmija, lai aprēķinātu faktisko atalgojumu, un līdzīgs process seko arī citiem darbinieku veidiem. Lai gan mūsu faktiskās algas aprēķināšanas algoritms ir ļoti vienkāršs, lai to būtu vieglāk saprast, taču lielākoties tas ietver daudzus salīdzinājumus un aprēķinus.

Tātad, kas ir nepareizs ar darbinieku klases kodu?

Nu, algas aprēķināšanas kods (getPay ()) ir statisks. Pieņemsim, ka es vēlos mainīt “Intern” prēmiju no 10% uz 14%. Man būs jāatver darbinieka klases kods un tas jāmaina.

Un vēl viena problēma ir tā, ka izpildes laikā es nevaru mainīt darbinieka algas algoritmu. Tātad, kā to izdarīt? Stratēģijas modelis ir īpaši izmantots šāda veida problēmu risināšanai.

Pārstrādāsim kodu, lai izmantotu stratēģijas modeli.

Es definēšu vairākus algoritmus, lai aprēķinātu atalgojumu. Tad es varēšu izmantot jebkuru no šiem algoritmiem, lai aprēķinātu atalgojumu izpildes laikā.

Apskatīsim, kā mainīsies darbinieku klase.

Piezīme: Esmu noņēmis algas aprēķināšanas loģiku no darbinieku klases un izveidojis noteiktu PayAlgorithm () metodi, ar kuras palīdzību es iestatīšu PayAlgorithm, kuru vēlos izmantot algas aprēķināšanai.

Tas man ļaus elastīgi aprēķināt atalgojumu, izpildes laikā dinamiski norādot jebkuru PayAlgorithm. Turklāt ņemiet vērā, ka vēlāk, ja man būs jāmaina algas aprēķināšanas loģika, es varu izveidot jaunu PayAlgorithm un izmantot to algas aprēķināšanai. Man nav jāmaina iepriekšējais kods, vai tas nav lieliski?

Tāpēc redzēsim, ka tas darbojas.

Es ceru, ka jūs ļoti labi sapratāt stratēģijas modeli. Labākais veids, kā kaut ko iemācīties, ir praktizēšanās.

Ja jums ir kādi jautājumi par stratēģijas modeli vai jebkuru citu modeli, atstājiet savus jautājumus zemāk.

Uzmanieties no nākamā ieraksta, kur mēs atklāsim vienu no populārākajiem dizaina modeļiem, rūpnīcas modeli.

Līdz tam jūs varat lejupielādēt kodu ar to un pārliecināties, vai jūs savā galvā nostiprinājāt stratēģijas modeli.

Vai mums ir jautājums? Pieminiet tos komentāru sadaļā, un mēs ar jums sazināsimies.

Saistītās ziņas: