'
Sveiki atvykę į pirmąjį „Design Patterns Exposed“ serijos įrašą. Šioje serijoje kiekvieną dizaino modelį atskleisime nuo nulio.
Paprasčiausiai mokėdami programavimo kalbą ir jos konstrukcijas, jūs netapsite geresniu programuotoju ar kūrėju. Norint sukurti programinę įrangą, kuri veiks šiandien ir ateityje, reikia žinių apie dizaino modelius.
Daugelis kūrėjų jau susidūrė su tomis dizaino problemomis, su kuriomis susiduriate dabar arba susidursite ateityje. Jie nurodė standartinį šios problemos sprendimo būdą. Taigi naudodami dizaino modelius galite pasinaudoti patikrintų metodų pranašumu.
Kiekvienas dizaino modelis skirtas tam tikros situacijos sprendimui, gali būti situacijų, kai galima naudoti daugiau nei vieną dizaino modelį.
Dauguma programuotojų tiesiog bando išspręsti iškilusią problemą, nesijaudindami dėl dizaino modelių, nereikalingo kodo ar net glaudaus sujungimo. Bet geri programuotojai pradeda kitaip. Jie galvoja apie šiandieninius reikalavimus, būsimus reikalavimus, kodo priežiūrą ir pakartotinį kodo naudojimą.
Geri programuotojai, gavę reikalavimus, neskuba pradėti koduoti. Jie sėdi ir galvoja apie problemą, ar jų dizainas bus tinkamas. Jei taip, ar tai veiks po 6 mėnesių, kai pasikeis reikalavimai.
Geri programuotojai ima rašiklį ir popierių ir pradeda kurti savo klases bei santykius tarp klasių. Jie stengiasi, kad jų dizainas būtų laisvas ir nesusijęs, o visa tai darant jie turi į objektą orientuotus principus. Jie iš karto neįeina į žemo lygio kodą. Norėdami sukurti lanksčią ir daugkartinio naudojimo programinę įrangą, turėtumėte laikytis šio požiūrio, kitaip visada pastebėsite, kad modifikuojate anksčiau parašytą kodą.
Programinės įrangos pramonėje yra pastovus tik vienas dalykas ir tai yra Keisti. Reikalavimai tikrai keisis. Taigi, kaip sukurti programinę įrangą, kurią jūsų kodas galėtų lengvai pritaikyti prie būsimų reikalavimų? Tam turite pradėti anksti ir suprojektuoti taip, kad būsimi reikalavimai nepažeistų jūsų ankstesnio kodo.
Kaip aš tai galėčiau padaryti?
Na, tai galima padaryti vadovaujantis tais principais paremtais projektavimo principais ir modeliais.
Dabar pasinerkime į kodavimą ir pradėkime kelionę, norėdami tapti geresniu programuotoju. Šiame įraše mes atskleisime vieną iš svarbiausių modelių - Strategijos modelis .
Kai sakau, kad svarbiausia, tai atspindi bendrą problemą, kurią išsprendžia strategijos modelis.
Kas yra strategijos modelis?
Štai apibrėžimas tiesiai iš knygos „Keturių gauja“: „Strategijos modelis naudojamas sukurti keičiamą algoritmų šeimą, iš kurios vykdymo metu pasirenkamas reikalingas procesas“.
Tuo atveju, jei esatenesuprantu, nesijaudink, mes tai paaiškinsime apaprasčiaubūdutausuprasti.
Pirmiausia supraskime problemą ir tada pamatysime, kaip strategijos modelis gali tai išspręsti.
Pirmiau pateiktoje UML diagramoje mes turime gyvūnų abstrakčią klasę ir dvi konkrečias klases - Šuo ir Paukštis, besitęsiančią nuo Gyvūnų super klasės.
Taigi apibrėžkime abstrakčią gyvūnų klasę ir dvi konkrečias klases „Šuo ir paukštis“.
Ką manote apie pirmiau pateiktą dizainą? Mūsų dizaine yra viena didelė klaida.
Visi gyvūnai negali skristi, kaip ir aukščiau nurodytu atveju, šuo negali skristi. Bet vis tiek jis turi „musės“ elgesį.
Gyvūnų klasėje užrašėme abstrakčios musės () metodą. Šis dizainas privers kiekvieną subklasę „Šuo“, „Paukštis“, „Pingvinas“, „Krokodilas“, „Žąsis“ ir kt. Įgyvendinti „fly“) metodą.
Turėjome suprasti, kad skraidymas yra sugebėjimas, kurį turės ne visi gyvūnai. Pateikdami „fly ()“ metodą gyvūnų abstrakčioje klasėje, mes nustatėme skraidymo galimybes visose pogrupiuose, o tai nėra teisinga visoms gyvūnų pogrupiams.
Galite pagalvoti, kokia yra „fly“ metodo įgyvendinimo problema pogrupiuose. Nors jūs galite įgyvendinti „fly“ („fly“) metodą skraidančių gyvūnų pogrupiuose, kad tiesiog atspausdintumėte „Aš negaliu skristi“. Bet problema ta, kad jūs vis dar suteikiate musės elgesį neskraidantiems gyvūnams. Tai nėra teisinga.
Koks jausmas vadinti dog.fly () arba crocodile.fly ().
Taigi, dabar mes supratome, kad mūsų dizainas nėra teisingas, ir mes turėtume pašalinti musės () metodą iš gyvūnų subklasės.
Koks yra kitas būdas kurti savo klases taip, kad mūsų dizainas neužtikrintų visų gyvūnų pogrupių elgesio su musėmis.
Vienas sprendimas, kuris iš karto ateina į galvą, yra tas, kad mes galime sukurti skraidymo sąsają naudodami musės metodą ir tik skraidyti galintys gyvūnai įgyvendins tą skraidymo sąsają. Tokiu būdu neversime visų gyvūnų pogrupių apibrėžti musės elgesio. Taigi užkoduokime šį projektavimo metodą.
Dabar mūsų gyvūnų klasė atrodys kaip žemiau pateiktas kodas, pašalinus musių metodą iš gyvūnų klasės.
Dabar apibrėžkime „Flying“ sąsają
Dabar šunų klasė bus pakeistakaipžemiau pateiktą kodą ir jo elgesys nebūtinas.
Pažiūrėkime į keletą mūsų gyvūnų klasių, kurios elgsis skraidydamos.
Mes išsprendėme ankstesnę problemą, tačiau patyrėme naują bėdą, tai yra „Kodo dubliavimas“.
Tarkime, turėsime 100 skirtingų skraidančių gyvūnų pogrupių. Turime nukopijuoti skraidymo elgesio kodą, nes skraidymo sąsaja negali suteikti jokio pritaikymo skrydžio elgesiui, o vėliau, jei norime pakeisti „fly“) metodo įgyvendinimą bet kurioje subklasėje, turėsime atidaryti tą klasę ir pakeisti kodą, kas yra blogai. Mums trūksta kažko didelio ir, tai yra, negalime pakeisti klasės skraidymo elgesio bėgimo metu.
pradinio lygio python kūrėjas atnaujinti
Tačiau nesijaudinkite, strategijos modelis yra tam, kad išvengtumėte šios problemos.
Taigi pakeiskime kodą, kad galėtume naudoti strategijos modelį.
Skraidanti sąsaja išliks tokia pati, kokia yra. Vietoj to, kad kiekviena skraidymo subklasė įgyvendintų pačią skraidymo sąsają, mes nustatysime atskiras konkrečias klases, kurios įgyvendins skirtingą skraidymo elgesį. Pažiūrėkime, kaip tai padaryti.
Taigi, kaip visa tai veikia, pažiūrėkime „TestClass“
Naudodami strategijos modelį, mes dabar galime pakeisti bet kurio gyvūno skraidymo elgesį bėgimo metu, t. Y. Neįpareigojant jokių subklasių nurodyti patį skrydžio elgesį.
Kada naudoti strategijos modelį?
Kai norite dinamiškai pakeisti elgesį vykdymo metu.
Paimkime kitą pavyzdį, kad įsitikintumėte, jog aiškiai suprantate strategijos modelį.
Aukščiau pateiktoje „Darbuotojų“ klasėje mes nustatome darbuotojo atlyginimą, atsižvelgiant į jo / jos paskyrimą. Jei darbuotojas yra „internas“, apskaičiuojant faktinį darbo užmokestį, prie pagrindinio atlyginimo pridedame 10% premiją.
Jei darbuotojas yra „žiniatinklio kūrėjas“, prie pagrindinio atlyginimo pridedame 20% premiją, kad apskaičiuotume faktinį darbo užmokestį, ir panašus procesas vyksta ir kitų tipų darbuotojams. Nors faktinio darbo užmokesčio apskaičiavimo algoritmas yra labai paprastas, kad jį būtų lengviau suprasti, tačiau dažniausiai jis apima daugybę palyginimų ir skaičiavimų.
Taigi, kas yra negerai su darbuotojų klasės kodu?
Na, darbo užmokesčio skaičiavimo kodas (getPay ()) yra statiškas. Tarkime, kad noriu pakeisti „Intern“ premiją nuo 10% iki 14%. Turėsiu atidaryti „Employee“ klasės kodą ir jį pakeisti.
Kita problema yra ta, kad aš negaliu pakeisti darbuotojo darbo užmokesčio algoritmo vykdymo metu. Taigi, kaip tai padaryti? Strategijos modelis yra specialiai naudojamas tokio pobūdžio problemoms spręsti.
Pertvarkykime kodą, kad galėtume naudoti strategijos modelį.
Aš ketinu apibrėžti kelis algoritmus, kad apskaičiuočiau atlyginimą. Tada galėsiu naudoti bet kurį iš šių algoritmų apskaičiuoti atlyginimą vykdymo metu.
Pažiūrėkime, kaip keisis Darbuotojų klasė.
Pastaba: Aš pašalinau darbo užmokesčio skaičiavimo logiką iš „Darbuotojų klasės“ ir sukūriau nustatytą „PayAlgorithm“ () metodą, per kurį nustatysiu „PayAlgorithm“, kurį noriu naudoti skaičiuojant atlyginimą.
Tai suteiks man lankstumo apskaičiuoti atlyginimą, nurodant bet kurį „PayAlgorithm“ dinamiškai vykdymo metu. Be to, atkreipkite dėmesį, kad vėliau, jei turėsiu pakeisti darbo užmokesčio apskaičiavimo logiką, galiu sukurti naują „PayAlgorithm“ ir naudoti tai apskaičiuoti atlyginimą. Man nereikia keisti ankstesnio kodo, ar ne puiku?
Taigi pažiūrėkime, kaip tai veikia.
Tikiuosi, kad jūs labai gerai supratote strategijos modelį. Geriausias būdas ko nors išmokti yra praktika.
Jei turite klausimų, susijusių su strategijos modeliu ar kitu modeliu, palikite savo klausimus žemiau.
Saugokitės kito įrašo, kuriame mes atskleisime vieną populiariausių dizaino modelių - gamyklos modelį.
Iki to laiko galite atsisiųsti kodą su juo ir įsitikinkite, kad įtvirtinote strategijos modelį savo galvoje.
Turite mums klausimą? Paminėkite juos komentarų skiltyje ir mes susisieksime su jumis.
Susijusios žinutės: