'
Tere tulemast sarja „Disainmustrid paljastatud“ esimesse postitusse. Selles seerias paljastame iga kujunduse mustri nullist.
Lihtsalt programmeerimiskeele ja selle konstruktsioonide tundmine ei muuda teid paremaks programmeerijaks ega arendajaks. Täna ja ka tulevikus toimiva tarkvara loomiseks on vaja disainimustrite tundmist.
Paljud arendajad on juba kokku puutunud nende disainiprobleemidega, mis teil praegu ees seisavad või tulevikus silmitsi seisavad. Nad on määranud selle probleemi lahendamiseks tavapärase viisi. Nii saate disainimustrite abil eeliseks tõestatud tehnikate kasutamise.
Iga kujundusmuster on mõeldud teatud tüüpi olukorra lahendamiseks, võib esineda olukordi, kus saab kasutada mitut kujundusmustrit.
Enamik programmeerijatest püüab lihtsalt lahendada probleem, millega nad silmitsi seisavad, vaevamata disainimustrite, üleliigse koodi või isegi tiheda ühendamise pärast. Kuid head programmeerijad alustavad teisiti. Nad mõtlevad tänapäevastele nõuetele, tulevastele nõuetele, koodi hooldamisele ja koodi taaskasutatavusele.
Head programmeerijad ei kiirusta kodeerimisega alustama, kui nad on nõuete kätte saanud. Nad istuvad ja mõtlevad probleemile, kas nende disain töötab. Kui jah, siis kas see töötab kuue kuu pärast, kui nõuded muutuvad.
Head programmeerijad võtavad oma pastaka ja paberi ning hakkavad oma tunde ja klassidevahelisi suhteid kujundama. Nad püüavad oma disainis vabalt siduda ja saavutada ühtekuuluvust, samal ajal kui neil kõigil neil on meeles objektipõhised põhimõtted. Nad ei lähe madala taseme koodi kohe sisse. Paindliku ja korduvkasutatava tarkvara kujundamiseks peaksite järgima seda lähenemisviisi, vastasel juhul leiate end alati varem kirjutatud koodi muutmas.
Tarkvaratööstuses on püsiv ainult üks asi ja see on Muuda. Nõuded muutuvad kindlasti pidevalt. Niisiis, kuidas kujundada tarkvara, mida teie kood saab hõlpsalt kohandada tulevaste nõudmistega? Selleks peate alustama varakult ja kujundama selle nii, et tulevased nõuded ei rikuks teie eelmist koodi.
Kuidas ma seda teha saan?
Noh, seda saab teha, järgides nendel põhimõtetel põhinevaid kujunduspõhimõtteid ja kujundusmustreid.
Sukeldume nüüd kodeerimisse ja alustame teekonda, et saada paremaks programmeerijaks. Selles postituses avastame ühe kõige olulisema mustri - strateegia muster .
Kui ma ütlen, et kõige olulisem, siis see kajastub strateegiamustriga lahendatud levinud probleemil.
Mis on strateegiamuster?
Siin on määratlus otse raamatust “Nelja jõuk”:Strateegiamustrit kasutatakse vahetatavate algoritmide perekonna loomiseks, mille hulgast valitakse vajalik protsess”.
Juhul kui oleteei suuda aru saada, ärge muretsege, me selgitame seda alihtsamteeteie jaoksaru saama.
Mõistame kõigepealt probleemi ja siis näeme, kuidas strateegiamudel selle lahendada suudab.
Ülaltoodud UML-diagrammil on loomade abstraktne klass ja kaks konkreetset klassi, koer ja lind, mis ulatuvad loomade superklassist.
Nii et määratleme loomade abstraktne klass ja kaks konkreetset klassi, koer ja lind.
Mida arvate ülaltoodud kujundusest? Meie kujunduses on üks suur viga.
Kõik loomad ei saa lennata, nagu ülalnimetatud juhul, kui koer ei saa lennata. Kuid sellegipoolest on sellel „kärbse“ käitumine.
Tegime vea, kirjutades abstraktse kärbse () meetodi loomaklassi sisse. See disain sunnib kõiki alamklassi Koer, Lind, Pingviin, Krokodill, Hani jne rakendama meetodit fly ().
Me oleksime pidanud mõistma, et lendamine on võime, mis kõigil loomadel puudub. Pakkudes fly () meetodit Animal abstraktses klassis, oleme seadnud kõigis alamklassides lennuvõime, mis pole kõigi loomade alamklasside puhul õige.
Võite mõelda, mis on kärbse meetodi rakendamise probleem alaklassides. Kuigi saate lennata loomade alamklassides rakendada fly () meetodit, et lihtsalt printida “Ma ei saa lennata”. Kuid probleem on selles, et annate endiselt kärbse käitumist mittelendavatele loomadele. See pole õige.
Mis tunne on kutsuda dog.fly () või krokodill.fly ().
Niisiis, nüüd oleme aru saanud, et meie disain ei ole õige ja me peaksime loomade alamklassist eemaldama meetodi fly ().
teisendades javas topelt int-ks
Mis on muul viisil meie klasside kujundamine nii, et meie kujundus ei sunniks kõiki loomade alamklasse kärbset käituma.
Üks lahendus, mis kohe meelde tuleb, on see, et me suudame luua lendamisliidese, kasutades kärbemeetodit, ja selle lennuliidese rakendavad ainult lennata oskavad loomad. Nii ei sunni me kõiki loomade alamklasse kärbse käitumise määratlemiseks. Nii et kodeerime selle disaini lähenemise.
Nüüd näeb meie loomaklass välja pärast kärbsemeetodi eemaldamist loomade klassist alloleva koodina.
Nüüd määratleme liidese Flying
Nüüd muudetakse koerte klassiasallolev kood ja see ei pea olema kärbsekäitumine.
Vaatame mõnda meie loomade alamklassi, millel on lennukäitumine.
Oleme oma eelmise probleemi lahendanud, kuid sattusime uude hätta ja see on koodide dubleerimine.
Oletame, et meil on 100 erinevat lendavate loomade alamklassi. Me peame lendude käitumise koodi dubleerima, kuna lennuliides ei võimalda lendude käitumiseks mingit rakendust ja hiljem, kui soovime muuta fly () meetodi juurutamist mis tahes alamklassis, peame selle klassi avama ja koodi muutma mis on halb. Meil on midagi suurt puudu ja see tähendab, et me ei saa muuta jooksuajal klassi lennukäitumist.
Kuid ärge muretsege, strateegia muster on selleks, et sellest probleemist välja tulla.
Refrakteerime strateegia mustri kasutamiseks koodi uuesti.
Lendliides jääb endiseks. Selle asemel, et iga lendav alamklass rakendaks ise lennuliidest, määratleme eraldi konkreetsed klassid, mis rakendavad erinevat lennukäitumist. Vaatame, kuidas seda teha.
Niisiis, kuidas see kõik töötab, vaatame TestClassi
Strateegiamustri abil saame nüüd muuta iga looma lennukäitumist jooksuajal ja see tähendab, et ilma sundimata ühtegi alamklassi lennukäitumist ise täpsustama.
Millal strateegiamustrit kasutada?
Kui soovite, et käitamise käitumist saaks dünaamiliselt muuta.
Selleks, et saaksite strateegiamustrist selgelt aru, võtame veel ühe näite.
Ülaltoodud töötajate klassis määrame töötaja töötasu sõltuvalt tema määramisest. Kui töötaja on praktikant, lisame tegeliku palga arvutamiseks põhipalgale 10% lisatasu.
Kui töötaja on veebiarendaja, lisame tegeliku palga arvutamiseks põhipalgale 20% lisatasu ja sarnane protsess järgneb ka muud tüüpi töötajatele. Kuigi meie tegeliku palga arvutamise algoritm on arusaadavuse huvides väga lihtne, kuid enamasti sisaldab see palju võrdlusi ja arvutusi.
Niisiis, mis on töötaja klassi koodiga valesti?
Noh, töötasu arvutamise kood (getPay ()) on staatiline. Oletame, et tahan muuta praktikandi boonust 10% -lt 14% -le. Pean avama Employee-klassi koodi ja muutma seda.
Ja veel üks probleem on see, et ma ei saa jooksuajal muuta töötaja palgaalgoritmi. Niisiis, kuidas seda teha? Strateegiamustrit kasutatakse spetsiaalselt sellise probleemi lahendamiseks.
Refrakteerime koodi strateegiamustri kasutamiseks.
Töötasu arvutamiseks määratlen mitu algoritmi. Siis saan kasutada mis tahes neist algoritmidest jooksuajal palga arvutamiseks.
Vaatame nüüd, kuidas töötajate klass muutub.
Märge: Olen eemaldanud palgaarvestuse loogika töötajate klassist ja loonud komplekti PayAlgorithm () meetodi, mille kaudu määran PayAlgorithmi, mida soovin palgaarvestuses kasutada.
See annab mulle paindlikkuse palga arvutamiseks, määrates mis tahes PayAlgorithm-i dünaamiliselt jooksuajal. Pange tähele ka seda, et kui pean hiljem palgaarvestuse loogikat muutma, saan luua uue PayAlgorithmi ja kasutada seda palga arvutamiseks. Mul pole vaja eelmist koodi muuta, kas pole tore?
Nii et vaatame, kuidas see töötab.
Loodan, et saite strateegiamustrist väga hästi aru. Parim viis midagi õppida on harjutamine.
Kui teil on strateegiamustriga või mõne muu mustriga seotud küsimusi, jätke oma päringud allpool.
parim java ide algajatele
Jälgige järgmist postitust, kus avastame ühe populaarseima kujundusmustri, tehase mustri.
Siiani saate koodimängu sellega alla laadida ja veenduge, et olete strateegiamustri oma peas kinnistanud.
Kas teil on meile küsimus? Mainige neid kommentaaride jaotises ja võtame teiega ühendust.
Seonduvad postitused: