'
Dobrodošli v prvi objavi serije 'Oblikovani vzorci'. V tej seriji bomo vsak vzorec oblikovanja odkrili iz nič.
Preprosto poznavanje programskega jezika in njegovih konstrukcij ne bo postalo boljši programer ali razvijalec. Za ustvarjanje programske opreme, ki bo delovala danes in tudi v prihodnosti, je potrebno znanje o vzorcih oblikovanja.
Številni razvijalci so že naleteli na tiste težave pri oblikovanju, s katerimi se soočate zdaj ali pa se boste soočili v prihodnosti. Določili so standardni način reševanja te težave. Torej z uporabo vzorčnih vzorcev dobite prednost uporabe preizkušenih tehnik.
Vsak vzorec vzorca je namenjen reševanju določene vrste situacij, v nekaterih primerih lahko uporabimo več vzorcev vzorcev.
Večina programerjev samo poskuša rešiti težavo, s katero se soočajo, ne da bi se mučili glede vzorcev oblikovanja, odvečne kode ali celo tesnega spenjanja. Toda dobri programerji začnejo drugače. Razmišljajo o današnjih zahtevah, prihodnjih zahtevah, vzdrževanju kode in ponovni uporabi kode.
Dobri programerji se ne mudijo s kodiranjem, ko dobijo zahteve. Sedejo in razmišljajo o težavi, ali bo njihov dizajn uspel. Če je odgovor da, ali bo delovalo po 6 mesecih, ko se bodo zahteve spremenile.
Dobri programerji vzamejo pero in papir in začnejo oblikovati svoje razrede in razmerje med razredi. Pri svojem oblikovanju poskušajo dobiti ohlapne sklopke in visoko kohezijo, pri tem pa imajo v mislih objektno usmerjena načela. V kodo nizke ravni ne gredo takoj. Za oblikovanje prilagodljive programske opreme in programske opreme za večkratno uporabo upoštevajte ta pristop, sicer boste vedno sami spreminjali kodo, ki ste jo napisali prej.
Samo ena stvar je stalna v industriji programske opreme in to je Spremeni se. Zahteve se bodo gotovo spreminjale. Torej, kako oblikujemo programsko opremo, ki se bo vaša koda zlahka prilagodila prihodnjim zahtevam? Za to morate začeti zgodaj in ga oblikovati tako, da prihodnje zahteve ne bodo zlomile vaše prejšnje kode.
Kako lahko to storim?
No, to lahko storite tako, da sledite načelom oblikovanja in vzorcem oblikovanja, ki temeljijo na teh načelih.
Zdaj pa se poglobimo v kodiranje in začnimo na poti, da postanemo boljši programer. V tej objavi bomo odkrili enega najpomembnejših vzorcev - Strateški vzorec .
Ko rečem najpomembnejše, se to odraža na skupnem problemu, ki ga reši Strateški vzorec.
Kaj je strateški vzorec?
Tu je definicija naravnost iz knjige 'Gang of Four': 'Vzorec strategije se uporablja za ustvarjanje zamenljive družine algoritmov, iz katerih se med izvajanjem izbere zahtevani postopek'.
V primeru, da stene morem razumeti, ne skrbite, to bomo razložili v apreprostejšenačinza vasrazumeti.
Najprej razumemo težavo, nato pa bomo videli, kako lahko strateški vzorec to reši.
V zgornjem diagramu UML imamo abstraktni razred Animal in dva konkretna razreda, Dog in Bird, ki segata od super razreda Animal.
Določimo torej abstraktni razred živali in dva konkretna razreda, Dog in Bird.
Kaj menite o zgornji zasnovi? V našem oblikovanju je ena velika napaka.
Vse živali ne morejo leteti, kot v zgornjem primeru pes ne more leteti. A vseeno ima vedenje 'muhe'.
Napako smo naredili tako, da smo v razred Animal zapisali abstraktno metodo fly (). Ta zasnova bo prisilila vsak podrazred Pes, ptica, pingvin, krokodil, gos itd., Da uporabi metodo fly ().
Morali bi razumeti, da je letenje sposobnost, ki je ne bodo imele vse živali. Z zagotavljanjem metode fly () v abstraktnem razredu živali smo nastavili letenje v vseh podrazredih, kar ni pravilno za vse podrazrede živali.
Morda mislite, v čem je težava pri izvajanju metode letenja v podrazredih. Čeprav lahko metodo fly () uporabite v podrazredih za neleteče živali, da samo natisnete »Ne morem leteti«. Toda težava je v tem, da še vedno dajete muhe obnašanju neletalskim živalim. To ni pravilno.
Kakšen je občutek, če pokličete dog.fly () ali crocodile.fly ().
Zdaj smo razumeli, da naša zasnova ni pravilna in bi morali odstraniti metodo fly () iz podrazreda Animal.
Kateri je drugi način oblikovanja naših razredov na način, da naš dizajn ne vsiljuje vseh podrazredov živali letenja.
Ena od rešitev, ki mi takoj pade na misel, je, da lahko izdelamo leteči vmesnik z metodo letenja in le leteče vmesnike bodo implementirale letalstvo. Tako ne bomo uveljavili vseh podrazredov živali, da bi opredelili vedenje muhe. Torej, kodirajmo ta oblikovalski pristop.
Zdaj bo naš razred Animal videti kot spodnja koda po odstranitvi metode fly iz razreda Animal.
kako narediti kup v javi
Zdaj pa določimo leteči vmesnik
Zdaj bo razred psov spremenjenkotspodnjo kodo in ji ni treba obnašati letenja.
Poglejmo si nekaj naših podrazredov živali, ki se bodo obnašali leteče.
Prejšnjo težavo smo rešili, vendar smo zašli v novo težavo, in sicer »Podvajanje kod«.
Recimo, imeli bomo 100 različnih podrazredov letečih živali. Podvojiti moramo kodo vedenja letenja, saj leteči vmesnik ne more zagotoviti nobene izvedbe vedenja letenja, kasneje pa bomo, če želimo spremeniti izvedbo metode fly () v katerem koli podrazredu, morali odpreti ta razred in spremeniti kodo, kar je slabo. Manjka nam nekaj velikega, kar pomeni, da ne moremo spremeniti letečega vedenja razreda v času izvajanja.
A brez skrbi, Strateški vzorec vam pomaga rešiti težavo.
Torej preoblikujmo našo kodo, da bo uporabila vzorec strategije.
Leteči vmesnik bo ostal enak kot je. Zdaj bomo namesto vsakega letečega podrazreda, ki izvaja leteči vmesnik, opredelili ločene konkretne razrede, ki bodo izvajali različno vedenje letenja. Poglejmo, kako to narediti.
Torej, kako vse deluje, si oglejmo TestClass
Z uporabo vzorca strategije lahko zdaj spremenimo vedenje letenja katere koli živali v času izvajanja, in sicer brez uveljavljanja podrazredov za določanje samega letenja.
Kdaj uporabiti vzorec strategije?
Ko želite dinamično spremeniti vedenje med izvajanjem.
Vzemimo še en primer, da boste jasno razumeli vzorec strategije.
V zgornjem razredu Zaposleni določamo plačo zaposlenega glede na njegovo imenovanje. Če je zaposleni »pripravnik«, dodamo 10% dodatka k osnovni plači za izračun dejanske plače.
Če je zaposleni »spletni razvijalec«, dodamo 20% dodatka k osnovni plači za izračun dejanske plače, podoben postopek pa velja za druge vrste zaposlenih. Čeprav je naš algoritem za izračun dejanske plače zelo enostaven za lažje razumevanje, vendar večino časa vključuje veliko primerjav in izračunov.
Torej, kaj je narobe s kodo razreda zaposlenih?
No, koda za izračun plače (getPay ()) je statična. Recimo, da želim spremeniti bonus za 'pripravnika' z 10% na 14%. Moral bom odpreti kodo razreda Employee in jo spremeniti.
Druga težava pa je, da v času izvajanja ne morem spremeniti algoritma plače zaposlenega. Torej, kako to storiti? Strateški vzorec se posebej uporablja za reševanje tovrstnih težav.
Preoblikujmo kodo za uporabo vzorca strategije.
Določil bom več algoritmov za izračun plače. Potem bom lahko uporabil katerega koli od teh algoritmov za izračun plače med izvajanjem.
Zdaj pa poglejmo, kako se bo spremenil razred zaposlenih.
Opomba: Logiko izračuna plače sem odstranil iz razreda Employee in ustvaril nastavljeno metodo PayAlgorithm (), s pomočjo katere bom nastavil PayAlgorithm, ki ga želim uporabiti za izračun plače.
To mi bo omogočilo fleksibilnost pri izračunu plače z dinamičnim določanjem katerega koli PayAlgorithm v času izvajanja. Upoštevajte tudi, da lahko kasneje, če moram spremeniti logiko izračuna plače, ustvarim nov PayAlgorithm in ga uporabim za izračun plače. Prejšnje kode mi ni treba spreminjati, kajne?
Pa poglejmo, kako deluje.
Upam, da ste zelo dobro razumeli vzorec strategije. Najboljši način, da se česa naučite, je vadba.
Če imate kakršna koli vprašanja v zvezi s strateškim vzorcem ali katerim koli drugim vzorcem, pustite svoja vprašanja spodaj.
Pazite na naslednjo objavo, kjer bomo odkrili enega najbolj priljubljenih Design Pattern, Factory Pattern.
Do takrat lahko prenesete kodo, ki se igra z njo, in se prepričajte, da si v glavi utrdite strateški vzorec.
Imate vprašanje za nas? Omenite jih v oddelku za komentarje in javili se vam bomo.
kaj je tolmač v javi
Sorodne objave: