Johdatus luoviin suunnittelumalleihin

Johdanto

Ohjelmistotuotannossa suunnittelukuvio kuvaa vakiintuneen ratkaisun yleisimpiin ohjelmistojen ongelmiin design. Se edustaa parhaita käytäntöjä, jotka ovat kehittyneet pitkällä aikavälillä kokeneiden ohjelmistokehittäjien kokeilemisen kautta.

Suunnittelumallit saivat suosiota sen jälkeen, kun Erich Gamma julkaisi vuonna 1994 kirjan Design Patterns: Elements of Reusable Object-Oriented Software. , John Vlissides, Ralph Johnson ja Richard Helm (tunnetaan myös nimellä Neljän jengi tai GoF).

Tässä artikkelissa ”tutkimme luovia suunnittelumalleja ja niiden tyyppejä. Katsomme myös joitain koodimallit ja keskustele tilanteista, joissa nämä kuviot sopivat muotoiluumme.

Luovan suunnittelun mallit

Luovan suunnittelun mallit koskevat objektien luomistapaa. . Ne vähentävät monimutkaisuutta ja epävakautta luomalla objekteja hallitusti.

Uutta operaattoria pidetään usein haitallisena, koska se hajottaa esineitä kaikkialle sovellukseen. Ajan myötä toteutuksen muuttaminen voi olla haastavaa, koska luokat kytkeytyvät tiiviisti yhteen.

Luovan suunnittelun mallit korjaavat tämän ongelman irrottamalla asiakkaan kokonaan todellisesta alustamisprosessista.

Tässä artikkelissa , keskustelemme neljästä luovan suunnittelumallin tyypistä:

1. Singleton – varmistaa, että sovelluksessa on korkeintaan vain yksi esiintymä.
2. Tehdasmenetelmä – Luo useita toisiinsa liittyviä luokkia määrittelemättä tarkasti luotavaa objektia
3. Abstract Factory – Luo perheitä riippuvaisista objekteista
4. Builder – Rakentaa monimutkaisia objekteja vaiheittaisen lähestymistavan avulla

Tarkastellaan nyt kaikkia näitä malleja yksityiskohtaisesti.

Singleton-suunnittelukuvio

Singletonin suunnittelukuvion tarkoituksena on pitää tietyn luokan objektien alustamisen tarkistus varmistamalla, että vain yksi objektin esiintymä on olemassa Java-virtuaalikoneessa.

Singleton-luokka tarjoaa myös yhden ainutlaatuisen globaalin tukiaseman objektille siten, että jokainen seuraava yhteysosoitteen kutsu palauttaa vain kyseisen objektin.

3.1. Esimerkki Singletonin mallista

Vaikka GoF esitteli Singleton-mallin, alkuperäisen toteutuksen tiedetään olevan ongelmallinen monisäikeisissä skenaarioissa.

Joten tässä me ” seuraamme optimaalisempaa lähestymistapaa, joka käyttää staattista sisäistä luokkaa:

Tässä olemme luoneet staattisen sisäisen luokan, joka pitää sisällään Singleton-luokan esiintymän. Se luo ilmentymän vain, kun joku kutsuu getInstance () -metodia, eikä kun ulompi luokka ladataan.

Tämä on yleisesti käytetty lähestymistapa Singleton-luokalle, koska se ei vaadi synkronointia, on säiettä turvallinen , pakottaa laiskan alustuksen ja sillä on verrattain vähemmän kattilaa.

Huomaa myös, että rakentajalla on yksityisen pääsyn muokkaus. Tämä on vaatimus Singletonin luomiselle, koska julkinen rakennuttaja tarkoittaisi, että kuka tahansa voisi käyttää sitä ja aloittaa uusien ilmentymien luomisen.

Muista, että tämä ei ole alkuperäinen GoF-toteutus. Käy alkuperäisessä versiossa osoitteessa linkitetty Baeldung-artikkeli Singletoneista Javassa.

3.2. Milloin Singletonin suunnittelumallia tulisi käyttää

• Resursseille, joiden luominen on kallista (kuten tietokanta) yhteysobjektit)
• On hyvä käytäntö pitää kaikki kirjaajat yksinäisinä, mikä lisää suorituskykyä
• Luokat, jotka tarjoavat pääsyn sovelluksen kokoonpanoasetuksiin
• Luokat, jotka sisältää resursseja, joita käytetään jaetussa tilassa.

Tehdasmenetelmän suunnittelumalli

Tehdassuunnittelukuvio tai tehdasmenetelmäsuunnittelukuvio on yksi eniten käytetyt Java-suunnittelumallit.

GoF: n mukaan tämä malli ”määrittelee käyttöliittymän objektin luomiseksi, mutta antaa alaluokkien päättää, minkä luokan aloittaa tiate. Tehdas-menetelmä antaa luokan lykätä instantiation aliluokkiin. ”

Tämä malli siirtää vastuun luokan alustamisesta asiakkaalta tietylle tehdasluokalle luomalla tietyntyyppinen virtuaalinen konstruktori.

Tämän saavuttamiseksi luotamme tehtaaseen, joka toimittaa meille objektit ja piilottaa toteutuksen todelliset yksityiskohdat. Luotuihin kohteisiin pääsee käyttämällä yhteistä käyttöliittymää.

4.1. Tehdasmenetelmän suunnittelumalliesimerkki

Tässä esimerkissä luomme monikulmion käyttöliittymän, jonka toteuttaa useita konkreettisia luokkia. PolygonFactory-laitetta käytetään objektien hakemiseen tästä perheestä :

Luo ensin Polygon-käyttöliittymä:

Seuraava, Luomme muutaman toteutuksen, kuten Neliö, Kolmio jne., jotka toteuttavat tämän käyttöliittymän ja palauttavat Polygon-tyyppisen objektin.

Nyt voimme luoda tehtaan, joka ottaa argumenttina sivujen määrän ja palauttaa tämän käyttöliittymän asianmukaisen toteutuksen:

Huomaa, kuinka asiakas voi luottaa tähän tehtaaseen antamaan meille sopiva monikulmio ilman, että objektia on alustettava suoraan.

4.2. Milloin käytetään tehdasmenetelmän suunnittelumallia

• kun käyttöliittymän tai abstraktin luokan toteutuksen odotetaan muuttuvan usein
• kun nykyinen toteutus ei voi mukautua mukavasti uuteen muutokseen
• kun alustusprosessi on suhteellisen yksinkertainen ja rakentaja vaatii vain muutamia parametreja

tiivistelmä tehdasrakenteesta

Edellisessä osassa näimme, kuinka Factory Method -suunnittelukuviota voitiin käyttää luomaan yhteen perheeseen liittyviä esineitä.

Sitä vastoin käytetään Abstract Factory Design Patternia luoda toisiinsa liittyviä tai riippuvaisia esineitä. Sitä kutsutaan joskus myös tehtaiksi.

Yksityiskohtaisen selityksen saat tutustumalla Abstract Factory -oppaaseen.

Rakentajan suunnittelumalli

Rakentajan suunnittelumalli on toinen luova malli, joka on suunniteltu käsittelemään suhteellisen monimutkaisten objektien rakennetta.

Kun objektin luomisen monimutkaisuus lisääntyy, Builder-malli voi erottaa suoritusprosessin käyttämällä toista object (rakentaja) objektin rakentamiseksi.

Tätä rakennustyökalua voidaan sitten käyttää luomaan monia muita samanlaisia esityksiä yksinkertaisen vaiheittaisen lähestymistavan avulla.

6.1. Rakentajan malli Esimerkki

GoF: n esittämä alkuperäinen Builder Design Pattern keskittyy abstraktioon ja on erittäin hyvä käsiteltäessä monimutkaisia objekteja, mutta suunnittelu on kuitenkin hieman monimutkaista.

Joshua Bloch esitteli kirjassaan Effective Java rakennusmallin parannetun version, joka on puhdas, hyvin luettavissa (koska siinä käytetään sujuva muotoilu) ja helppo käyttää asiakkaan näkökulmasta. Tässä esimerkissä keskustelemme kyseisestä versiosta.

Tässä esimerkissä on vain yksi luokka, BankAccount, joka sisältää rakentajan staattisena sisäisenä luokkana:

Huomaa, että kaikki kenttien käyttömuokkaajat julistetaan yksityisiksi, koska emme halua, että ulkoiset objektit käyttävät niitä suoraan.

Rakentaja on myös yksityinen, joten vain tähän määritetty rakennustyökalu luokka voi käyttää sitä. Kaikki konstruktorin asetetut ominaisuudet erotetaan rakennusobjektista, jonka toimitamme argumenttina.

Olemme määrittäneet BankAccountBuilderin staattiseen sisäiseen luokkaan:

Huomaa, että olemme ilmoittaneet saman joukon kenttiä, jotka ulompi luokka sisältää. Pakolliset kentät vaaditaan argumentteina sisäisen luokan rakentajalle, kun taas muut valinnaiset kentät voidaan määrittää setterimenetelmillä.

Tämä toteutus tukee myös sujuvaa suunnittelutapaa antamalla setterimenetelmien palauttaa rakentajan object.

Viimeistään koontimenetelmä kutsuu ulomman luokan yksityisen konstruktorin ja välittää itsensä argumenttina. Palautettu BankAccount-yksikkö instantioidaan BankAccountBuilderin asettamilla parametreilla.

Katsotaanpa nopea esimerkki rakentajakuviosta toiminnassa:

6.2. Milloin rakennustyökalua käytetään

1. Kun objektin luomiseen liittyvä prosessi on erittäin monimutkainen, ja siinä on paljon pakollisia ja valinnaisia parametreja
2. kun rakentajaparametrien määrän kasvu johtaa suureen luetteloon rakentajista
3. Kun asiakas odottaa eri esityksiä rakennetulle objektille

Päätelmä

Tässä artikkelissa opimme Java-mallin luontisuunnittelumalleista ja keskustelimme myös niiden neljästä eri tyypistä, eli Singleton, Factory Method, Abstract Factory ja Builder Pattern, niiden eduista, esimerkeistä ja milloin käytämme niitä.

Kuten aina, täydelliset koodinpätkät ovat käytettävissä GitHubissa.