'
Tervetuloa “Design Patterns Exposed” -sarjan ensimmäiseen viestiin. Tässä sarjassa aiomme paljastaa jokaisen suunnittelukuvion tyhjästä.
Pelkkä ohjelmointikielen ja sen rakenteiden tunteminen ei tee sinusta parempaa ohjelmoijaa tai kehittäjää. Se vaatii suunnittelumallien tuntemusta luoda ohjelmisto, joka toimii tänään ja myös tulevaisuudessa.
Monet kehittäjät ovat jo kohdanneet ne suunnitteluongelmat, joita kohtaat nyt tai kohtaat tulevaisuudessa. He ovat määrittäneet tavanomaisen tavan käsitellä tätä ongelmaa. Joten käyttämällä Suunnittelumalleja saat edun todistettujen tekniikoiden käytöstä.
Jokainen suunnittelukuvio on tarkoitettu tietyntyyppisten tilanteiden ratkaisemiseen, saattaa olla tilanteita, joissa voidaan käyttää useampaa kuin yhtä mallikuviota.
Suurin osa ohjelmoijista yrittää vain ratkaista kohtaamansa ongelman huolehtimatta suunnittelumalleista, turhasta koodista tai edes tiukasta kytkennästä. Mutta hyvät ohjelmoijat aloittavat toisin. He ajattelevat tämän päivän vaatimuksia, tulevia vaatimuksia, koodin ylläpitoa ja koodin uudelleenkäytettävyyttä.
Hyvät ohjelmoijat eivät kiirehdi aloittamaan koodausta saatuaan vaatimukset. He istuvat ja miettivät ongelmaa siitä, toimiiko heidän suunnittelunsa. Jos kyllä, toimiiko se kuuden kuukauden kuluttua, jolloin vaatimukset muuttuvat.
Hyvät ohjelmoijat ottavat kynänsä ja paperinsa ja aloittavat luokkiensa ja luokkien välisen suhteen suunnittelun. He yrittävät saada löysän kytkennän ja korkean yhteenkuuluvuuden suunnittelussaan, samalla kun he tekevät kaikki nämä mielessään olio-periaatteet. He eivät mene matalan tason koodiin heti. Jos haluat suunnitella joustavia ja uudelleenkäytettäviä ohjelmistoja, sinun on noudatettava tätä lähestymistapaa, muuten huomaat aina muokkaavan aiemmin kirjoittamaasi koodia.
Ohjelmistoteollisuudessa on vakiona vain yksi asia ja se on Muuttaa. Vaatimukset muuttuvat varmasti jatkuvasti. Joten miten suunnitellaan ohjelmisto, jonka koodisi voi helposti mukauttaa tuleviin vaatimuksiin? Siksi sinun on aloitettava aikaisin ja suunniteltava se siten, että tulevat vaatimukset eivät riko edellistä koodiasi.
Miten voin tehdä sen?
No, se voidaan tehdä seuraamalla näihin periaatteisiin perustuvia suunnitteluperiaatteita ja -malleja.
Sukelletaan nyt koodaukseen ja aloitetaan matkalle paremmaksi ohjelmoijaksi. Tässä viestissä aiomme paljastaa yhden tärkeimmistä malleista - Strategiakuvio .
Kun sanon tärkeimmän, se heijastaa yhteistä ongelmaa, jonka strategiamalli ratkaisee.
Mikä on strategiamalli?
Tässä on määritelmä suoraan ”Neljän jengi” -kirjasta:Strategiakuviota käytetään luomaan vaihdettava algoritmiperhe, josta vaadittava prosessi valitaan ajon aikana”.
Jos oletei pysty ymmärtämään, älä huoli, aiomme selittää sen ayksinkertaisempitapasinulleymmärtää.
Ymmärretään ensin ongelma ja sitten nähdään, miten strategiamalli voi ratkaista sen.
Yllä olevassa UML-kaaviossa meillä on Animal abstrakti luokka ja kaksi konkreettista luokkaa, Dog and Bird, jotka ulottuvat Animal super -luokasta.
Joten määritellään eläin abstrakti luokka ja kaksi konkreettista luokkaa, koira ja lintu.
Mitä mieltä olet yllä olevasta suunnittelusta? Suunnittelussa on yksi iso virhe.
Kaikki eläimet eivät voi lentää, kuten yllä olevassa tapauksessa koira ei voi lentää. Mutta silti sillä on 'lentokäyttäytyminen'.
Teimme virheen kirjoittamalla abstraktin fly () -menetelmän eläinluokkaan. Tämä malli pakottaa jokaisen alaluokan Koira, Lintu, Pingviini, Krokotiili, Hanhi jne. Toteuttamaan fly () -menetelmän.
Meidän olisi pitänyt ymmärtää, että lentäminen on kyky, jota kaikilla eläimillä ei ole. Tarjoamalla fly () -menetelmän Animal abstraktiluokassa olemme asettaneet lentokyvyn kaikissa alaluokissa, mikä ei ole oikein kaikille eläinten alaluokille.
Saatat ajatella, mikä on ongelma fly-menetelmän toteuttamisessa alaluokissa. Vaikka voit toteuttaa fly () -menetelmän ei-lentävien eläinten alaluokissa vain tulostaa 'En voi lentää'. Mutta ongelma on, annat edelleen lentokäyttäytymisen muille kuin lentäville eläimille. Tämä ei ole oikein.
Miltä tuntuu kutsua dog.fly () tai krokotiili.fly ().
Joten nyt olemme ymmärtäneet, että suunnittelumme ei ole oikea ja meidän pitäisi poistaa fly () -menetelmä Animal-alaluokasta.
Mikä on toinen tapa suunnitella luokkiamme siten, että suunnittelumme ei pakota kaikkia eläinten alakategorioita olemaan perhokäyttäytyminen.
Yksi heti mieleen tuleva ratkaisu on, että voimme luoda lentävän käyttöliittymän lentomenetelmällä ja vain lentävät lentävät eläimet toteuttavat kyseisen lentävän käyttöliittymän. Näin emme pakota kaikkia eläinten alakategorioita määrittelemään lentokäyttäytymistä. Joten koodataan tämä suunnittelutapa.
Eläinluokkamme näyttää nyt alla olevalta koodilta poistettuasi lentomenetelmän eläinluokasta.
Määritellään nyt Flying-käyttöliittymä
Nyt koiraluokka muuttuukutenalla olevan koodin, eikä sillä tarvitse olla lentokäyttäytymistä.
linkitetty luettelo c-ohjelmassa
Katsotaanpa joitain eläinten alakategorioita, joilla on lentokäyttäytymistä.
Olemme ratkaisseet edellisen ongelmamme, mutta joutuimme uuteen ongelmaan, joka on koodin kopiointi.
Sano, että meillä on 100 erilaista lentävien eläinten alaluokkaa. Meidän on kopioitava lentokäyttäytymisen koodi, koska lentoliittymä ei tarjoa mitään toteutusta lentokäyttäytymiselle, ja myöhemmin, jos haluamme muuttaa fly () -menetelmän toteutusta missä tahansa alaluokassa, meidän on avattava kyseinen luokka ja muutettava koodi mikä on huono. Meiltä puuttuu jotain suurta, eli emme voi muuttaa luokan lentokäyttäytymistä ajon aikana.
Mutta älä huoli, strategiamalli auttaa sinua pääsemään ulos tästä ongelmasta.
Pienennetään siis koodiamme strategiakuvion käyttämiseksi.
Lentävä käyttöliittymä pysyy samana kuin se on. Sen sijaan, että kukin lentävä alaluokka toteuttaa itse lentoliittymän, aiomme määritellä erilliset konkreettiset luokat, jotka toteuttavat erilaisen lentokäyttäytymisen. Katsotaanpa, miten se tehdään.
Joten miten kaikki toimii, katsotaanpa TestClass
Strategiamallin avulla voimme nyt muuttaa minkä tahansa eläimen lentokäyttäytymistä ajon aikana eli ilman, että pakottaisimme alaryhmiä määrittelemään itse lentokäyttäytymistä.
Milloin strategiakuviota käytetään?
Kun haluat pystyä muuttamaan käyttäytymistä ajon aikana dynaamisesti.
Otetaan toinen esimerkki, jotta ymmärrät strategiamallin selvästi.
Edellä olevassa Työntekijäluokassa asetamme työntekijän palkan hänen nimityksestään riippuen. Jos työntekijä on ”harjoittelija”, lisätään peruspalkkaan 10%: n bonus todellisen palkan laskemiseksi.
Jos työntekijä on 'Web-kehittäjä', lisäämme 20%: n bonuksen peruspalkkaan todellisen palkan laskemiseksi ja samanlainen prosessi noudattaa muun tyyppisiä työntekijöitä. Vaikka algoritmimme todellisen palkan laskemiseksi on hyvin yksinkertainen helpottaa ymmärtämistä, mutta suurimman osan ajasta, se sisältää monia vertailuja ja laskelmia.
Joten, mikä vikaa työntekijäluokan koodissa?
No, palkanlaskentakoodi (getPay ()) on staattinen. Oletetaan, että haluan muuttaa “Intern” -bonuksen 10 prosentista 14 prosenttiin. Minun on avattava Employee-luokan koodi ja vaihdettava se.
Ja toinen ongelma on, että en voi muuttaa työntekijän palkka-algoritmia ajon aikana. Joten miten se tehdään? Strategiakuviota käytetään nimenomaan tällaisten ongelmien käsittelemiseen.
Refraktoidaan koodi strategiakuvion käyttämiseksi.
Aion määritellä useita algoritmeja palkan laskemiseksi. Sitten voin käyttää mitä tahansa näistä algoritmeista palkan laskemiseksi ajon aikana.
Katsotaan nyt, kuinka työntekijäluokka muuttuu.
Huomautus: Olen poistanut palkanlaskentalogiikan Työntekijäluokasta ja luonut joukon PayAlgorithm () -menetelmää, jonka avulla asetan PayAlgorithmin, jota haluan käyttää palkanlaskennassa.
Tämä antaa minulle joustavuuden laskea palkka määrittämällä mikä tahansa PayAlgorithm dynaamisesti ajon aikana. Huomaa myös, että jos minun on myöhemmin muutettava palkanlaskentalogiikkaa, voin luoda uuden PayAlgorithmin ja käyttää sitä palkan laskemiseen. Minun ei tarvitse muuttaa edellistä koodia, eikö olekin hienoa?
Katsotaan siis, että se toimii.
Toivon, että ymmärrät strategiamallin hyvin. Paras tapa oppia jotain on harjoittelu.
Jos sinulla on kysyttävää strategiakuviosta tai muusta mallista, jätä kyselysi alle.
Varo seuraavaa viestiä, jossa paljastamme yhden suosituimmista Design Patternista, Factory Patternista.
Siihen asti voit ladata koodipelin sen kanssa ja varmista, että sementoit strategiakuvion päähäsi.
Onko sinulla kysymys meille? Mainitse ne kommenttiosassa ja palaamme sinuun.
Aiheeseen liittyvät julkaisut: