7 tärkeintä ohjelmistosuunnittelumallia

Tutustu ohjelmistosuunnittelumallien kattavaan syvälle ohjelmasuunnittelumallien aiheesta: Ohjelmistosuunnittelumallit: Parhaat käytännöt kehittäjille, luonut C.H. Afzal, veteraani-ohjelmistoinsinööri, jolla on monen vuoden kokemus Netflixistä, Microsoftista ja Oraclesta. Suuri osa alla olevista on yhteenveto hänen kurssistaan.

Miksi suunnitella kuvioita?

Suunnittelumallit ovat viime aikoina tulleet kiistanalaisiksi ohjelmointimaailman kiistakysymyksiksi, mikä johtuu pitkälti niiden ymmärtämättömästä "liiallisesta käytöstä", joka johtaa koodiin, jota voi olla vaikeampi ymmärtää ja hallita.

On tärkeätä ymmärtää, että Suunnittelumallit eivät ole koskaan olleet tarkoitettu hakkeroituneiksi pikakuvakkeiksi, jotta niitä voidaan käyttää sattumanvaraisesti, "yksi koko sopii kaikille" koodiin. Ohjelmistosuunnittelussa ei lopulta voida korvata aitoa ongelmanratkaisukykyä.

Tosiasia on kuitenkin, että suunnittelumallit voivat olla uskomattoman hyödyllisiä, jos niitä käytetään oikeissa tilanteissa ja oikeista syistä. Strategisesti käytettynä ne voivat tehdä ohjelmoijasta huomattavasti tehokkaamman, koska ne voivat välttää sananlaskupyörän keksimisen sen sijaan, että käyttävät jo muiden puhdistamia menetelmiä. Ne tarjoavat myös hyödyllisen yhteisen kielen toistuvien ongelmien ja ratkaisujen käsitteellistämiseksi, kun keskustellaan muiden kanssa tai hallitaan koodia suurempissa ryhmissä.

Tärkeä huomautus on kuitenkin varmistaa, että kehittäjä ymmärtää myös kunkin mallin takana olevan tapan ja miksi.

Ilman lisäohjeita (yleisessä tärkeysjärjestyksessä, suurimmasta vähiten):

Tärkeimmät suunnittelumallit

  1. Singleton

Singleton-mallia käytetään rajoittamaan luokan luominen vain yhteen esineeseen. Tämä on hyödyllistä, kun tarvitaan yksi (ja vain yksi) objekti toiminnan koordinoimiseksi koko järjestelmässä. On olemassa useita esimerkkejä siitä, että vain yhden luokan esiintymän pitäisi olla olemassa, mukaan lukien välimuistit, säiepooli ja rekisterit.

Luokan objektin aloittaminen on triviaalia - mutta kuinka varmistamme, että vain yksi objekti luodaan koskaan? Vastaus on, että rakentaja tehdään 'yksityiseksi' luokalle, jonka aiomme määritellä singletoniksi. Tällä tavalla vain luokan jäsenet pääsevät yksityiseen rakentajaan eikä kukaan muu.

Tärkeä huomio: Yksittäisluokan alaluokka on mahdollista tekemällä rakentaja suojatuksi yksityisen sijasta. Tämä saattaa olla sopiva tietyissä olosuhteissa. Yksi näissä skenaarioissa käytetty lähestymistapa on luoda alaluokkien singletonien rekisteri, ja getInstance-menetelmä voi ottaa parametrin tai käyttää ympäristömuuttujaa palauttaaksesi halutun singleton. Rekisteri ylläpitää sitten merkkijonon nimien kartoitusta singleton-objekteiksi, joihin pääsee tarvittaessa.

2. Tehdasmenetelmä

Normaali tehdas tuottaa tavaroita; ohjelmistotehdas tuottaa esineitä. Eikä vain - se tekee niin määrittelemättä luotavan objektin tarkkaa luokkaa. Tämän saavuttamiseksi objektit luodaan kutsumalla tehdasmenetelmää rakentajan kutsumisen sijasta.

Objektien luominen Java-sovelluksissa tapahtuu yleensä seuraavasti:

SomeClass someClassObject = uusi SomeClass ();

Yllä olevan lähestymistavan ongelma on, että SomeClass-objektia käyttävä koodi muuttuu yhtäkkiä SomeClassin konkreettisen toteutuksen kohdalle. Ei ole mitään vikaa uusien käyttämisessä objektien luomiseen, mutta mukana tulee matkalaukku, joka kytkee tiukasti koodimme konkreettiseen toteutusluokkaan, mikä voi joskus olla ongelmallista.

3. Strategia

Strategiakuvio sallii liittyvien algoritmien ryhmittelyn abstraktin alla, mikä mahdollistaa yhden algoritmin tai käytännön vaihtamisen toiselle muuttamatta asiakasta. Sen sijaan, että suorittaisi suoraan yhden algoritmin, koodi vastaanottaa ajonaikaiset ohjeet, jotka määrittelevät, mitä algoritmien ryhmästä ajetaan.

4. Tarkkailija

Tämä kuvio on objektien välinen riippuvuus yhdestä monelle, joten kun yksi objekti muuttuu tilaan, kaikki sen riippuvaiset ilmoitetaan. Tämä tapahtuu tyypillisesti kutsumalla yhteen heidän menetelmistä.

Mieti, yksinkertaisuuden vuoksi mitä tapahtuu, kun seuraat jotakuta Twitterissä. Pyydät pohjimmiltaan Twitteriä lähettämään sinulle (tarkkailijalle) tweet-päivitykset seuraamastasi henkilöstä (aiheesta). Kuvio koostuu kahdesta näyttelijästä, tarkkailijasta, joka on kiinnostunut päivityksistä, ja aiheesta, joka tuottaa päivitykset.

Kohteella voi olla monia tarkkailijoita, ja hänellä on suhde moniin. Tarkkailija voi kuitenkin vapaasti tilata päivityksiä myös muista aiheista. Voit tilata uutissyötteen Facebook-sivulta, josta aihe olisi, ja aina, kun sivulla on uusi viesti, tilaaja näkee uuden viestin.

Tärkein huomio: Jos jokainen kohde tallentaa tarkkailijansa erikseen, monien kohteiden ja harvojen tarkkailijoiden tapauksessa se kasvattaa varastointikustannuksia, koska jotkut kohteet varastoivat saman tarkkailijan useita kertoja.

5. Rakentaja

Kuten nimestä voi päätellä, esineiden rakentamiseen käytetään rakennusmallia. Joskus luomme objektit voivat olla monimutkaisia, koostua useista alaobjekteista tai vaatia yksityiskohtaista rakennusprosessia. Monimutkaisten tyyppien luomista voidaan yksinkertaistaa käyttämällä rakennusmallia. Yhdistelmä- tai yhdistelmäobjekti on mitä rakentaja yleensä rakentaa.

Tärkein huomio: Rakennusmalli saattaa tuntua samanlaiselta kuin 'abstrakti tehdasmalli', mutta erona on se, että rakennusmalli luo kohteen askel askeleelta, kun taas abstrakti tehdaskuvio palauttaa kohteen yhdellä kertaa.

6. Sovitin

Tämä antaa yhteensopimattomien luokkien toimia yhdessä muuttamalla yhden luokan rajapinnan toiseksi. Ajattele sitä eräänlaisena kääntäjänä: kun kaksi valtioiden päämiestä, jotka eivät puhu yhteistä kieltä, tapaavat, yleensä tulkki istuu kahden välillä ja kääntää keskustelun, mikä mahdollistaa viestinnän.

Jos sinulla on kaksi sovellusta, joista toinen sylkee tulosteen XML-muodossa ja toinen vaatii JSON-syöttöä, tarvitset niiden välille sovittimen, jotta ne toimivat saumattomasti.

7. Valtio

Tilakuvio kapseloi ne eri tilat, joissa kone voi olla, ja sallii esineen muuttaa käyttäytymistään, kun sen sisäinen tila muuttuu. Kone tai konteksti, kuten sitä kutsutaan malli-puhetta varten, voi toteuttaa siihen toimenpiteitä, jotka ajavat sen eri tiloihin. Ilman kuvion käyttöä koodista tulee joustamaton ja täynnä if-else-ehdollisia.

Haluatko jatkaa oppimista?

Ohjelmistosuunnittelumallien avulla: Parhaat käytännöt kehittäjille sinulla on mahdollisuus tehdä muutakin kuin vain lukea teoriaa. Pystyt sukeltamaan syvälle todellisiin ongelmiin ja ymmärtämään käytännön ratkaisuja tosielämän koodimallien avulla.

Kurssi perustuu Gang of Four -lehden suosittuun kirjaan, mutta se esitetään interaktiivisessa, helposti sulatettavassa muodossa. Opiskelija hallitsee kirjasta kuuluisat 23 kuuluvaa suunnittelumallia vuorovaikutteisesti, oppii kolmen keskeisen suunnittelumallityypin (luominen, rakenne ja käyttäytyminen) oikeat sovellukset ja oppii sisällyttämään nämä suunnittelumallit omaan projektiisi.

Katso nyt.

Alun perin julkaistu osoitteessa blog.educative.io 7. marraskuuta 2018.