suunnittelumallit ovat suunnittelutason ratkaisuja toistuviin ongelmiin, joihin me ohjelmistoinsinöörit törmäämme usein. Se ei ole koodi – toistan, ❌koodi. Se on kuin kuvaus siitä, miten näihin ongelmiin voidaan puuttua ja suunnitella ratkaisu.
Käyttämällä näitä malleja pidetään hyvä käytäntö, koska suunnittelu ratkaisu on varsin kokeiltu ja testattu, tuloksena korkeampi luettavuutta lopullinen koodi., Suunnittelukuvioita luodaan ja käytetään usein OOP-kielille, kuten Javalle, jossa suurin osa esimerkeistä tästä eteenpäin kirjoitetaan.
erilaisia suunnittelumalleja
On noin 26 Kuviot tällä hetkellä löytänyt (en usko, aion tehdä ne kaikki…).
nämä 26 voidaan luokitella 3 tyyppiin:
1. Creational: nämä kuviot on suunniteltu luokan instantiation. Ne voivat olla joko luokkaluomiskuvioita tai objektiluomiskuvioita.
2. Rakenne: nämä kuviot on suunniteltu luokan rakenteen ja koostumuksen suhteen., Useimpien näiden mallien päätavoitteena on lisätä kyseessä olevan luokan(es) toimivuutta muuttamatta suurta osaa sen koostumuksesta.
3. Käyttäytyminen: nämä kuviot on suunniteltu sen mukaan, miten yksi luokka kommunikoi muiden kanssa.
tässä viestissä käydään läpi yksi perusrakenne jokaiselle luokitellulle tyypille.
Tyyppi 1: Creational – Singleton suunnittelumalli
Singleton suunnittelumalli on Creational malli, jonka tavoitteena on luoda vain yksi esiintymä luokan, ja tarjota vain yksi maailmanlaajuinen yhteysosoite, jos haluat, että objekti., Yksi yleisesti käytetty esimerkki tällaisesta luokasta Jaavalla on kalenteri,jossa ei voi tehdä kyseistä luokkaa. Se käyttää myös omaa getInstance() – menetelmää saadakseen objektin käyttöön.
– luokan singleton suunnittelumalli sisältää,
- yksityinen staattinen muuttuja, jolla vain esimerkiksi luokan.
- yksityinen rakentaja, joten sitä ei voi asentaa muualle.
- a public static method, to return the single instance of the class.,
On olemassa monia erilaisia toteutuksia singleton design. Tänään käyn läpi toteutukset;
1. Innokas Instantiaatio
2. Laiska Instantiaatio
3. Thread-safe-Instanssien
Innokas Majava
public class EagerSingleton {// create an instance of the class.private static EagerSingleton instance = new EagerSingleton();// private constructor, so it cannot be instantiated outside this class.private EagerSingleton() { }// get the only instance of the object created.public static EagerSingleton getInstance() {return instance;}}Tämän tyyppinen toteutuksen aikana tapahtuu luokan lastaus, sillä instanssien muuttujan oikeusasteen tuomioistuimen ulkopuolella tapahtuu mitä tahansa menetelmää. Tämä aiheuttaa mojovan haittapuolen, jos asiakassovellus ei käytä tätä luokkaa lainkaan. Varasuunnitelma, jos tätä luokkaa ei käytetä, on laiska Instantiaatio.,
Laiska Päivää
ei ole paljon ero edellä täytäntöönpanoa. Tärkeimmät erot ovat, että staattinen muuttuja on alun perin ilmoittanut, null, ja on vain instantiated sisällä getInstance() menetelmä, jos – ja vain jos – esimerkiksi muuttuja pysyy null aikaan tarkistaa.
Tämä korjaa yhden ongelman, mutta toinen on vielä olemassa. Entä jos kaksi eri asiakasta pääsee Singleton-tunnille samaan aikaan, millisekunnille?, No, ne tarkistaa, jos esiintymä on null samaan aikaan, ja löytää se on totta, ja niin luoda kaksi tapausta luokan kunkin pyynnön kaksi asiakasta. Tämän korjaamiseksi, Lanka turvallinen instantiation on toteutettava.
(Kierre) Turvallisuus on Keskeinen
Javassa avainsana synchronized käytetään menetelmiä tai esineitä toteuttaa lanka turvallisuutta, niin että vain yksi säie pääsee tietty resurssi kerrallaan. Luokan instantiaatio laitetaan synkronoituun lohkoon niin, että menetelmään pääsee vain yksi asiakas kerrallaan.,
synkronoidun menetelmän yleiskustannukset ovat korkeat, ja ne heikentävät koko operaation suorituskykyä.
esimerkiksi, jos esimerkiksi muuttuja on jo ollut instantiated, niin aina, kun asiakas käyttää getInstance() tapa synchronized menetelmä on ajaa ja suorituskyky laskee. Tämä tapahtuu vain sen tarkistamiseksi, onko instance muuttujien arvo null. Jos se havaitsee, että se on, se jättää menetelmän.
tämän ylimenon vähentämiseksi käytetään kaksoislukitusta., Tarkista käytetään ennen synchronized menetelmä kuin hyvin, ja jos arvo on null yksin, ei synchronized tapa ajaa.
Nyt seuraavaan luokitukseen.
Tyyppi 2: Rakenne – Sisustaja suunnittelumalli
aion antaa sinulle pienet skenaario antaa paremman yhteydessä, miksi ja missä sinun pitäisi käyttää Sisustusarkkitehti Kuvio.
Sano et oma kahvila, ja kuten kaikki newbie, voit aloittaa vain kaksi tavallista kahvia, talo sekoitus ja tumma paahto., Laskutusjärjestelmässäsi oli yksi luokka eri kahvisekoituksille, joka perii juoman abstraktin luokan. Ihmiset todella alkavat tulla ja on ihana (vaikkakin katkera?) kahvia. Sitten ovat kahviuutiset, jotka, luoja paratkoon, haluavat sokeria tai maitoa. Mikä irvikuva kahvista!! ??
nyt tarvitset myös nämä kaksi lisäosaa sekä valikkoon että valitettavasti laskutusjärjestelmään. Alun perin IT-henkilö tekee alaluokka sekä kahvia, mukaan lukien sokeri, toinen maitoa., Sitten, koska asiakkaat ovat aina oikeassa, sanotaan nämä pelätyt sanat:
”Saisinko maitokahvin, jossa on sokeria, kiitos?”
???
siellä menee laskutusjärjestelmä taas nauraen päin naamaa. No, takaisin piirustuspöydälle….
IT-henkilö lisää sen jälkeen maitokahvin sokerilla toiseksi alaluokaksi kuhunkin emokahviluokkaan. Loppukuukausi on sujuvaa purjehdusta, ihmiset jonottavat kahville, sinä todella tienaat rahaa. ??
But wait, there ’ s more!
maailma on sinua vastaan jälleen kerran., Kadun toiselle puolelle aukeaa kilpailija, jossa ei ole vain 4 erilaista kahvia, vaan myös yli 10 lisäosaa! ?
ostat kaikki ne ja enemmän, myydäksesi itse parempaa kahvia, ja muista vain sitten, että unohdit päivittää tuon dratted-laskutusjärjestelmän. Et voi mitenkään tehdä ääretön määrä alaluokkien mitään ja kaikki yhdistelmät kaikki lisäosat, uuden Kahvin sekoituksia liian. Puhumattakaan lopullisen järjestelmän koosta.??
aika todella investoida asianmukaiseen laskutusjärjestelmään., Löydät uusia IT-henkilöstö, jotka todella tietävät, mitä he tekevät ja sanovat,
”Miksi tämä on niin paljon helpompaa, ja pienempi, jos sitä käytetään sisustusarkkitehti kuvio.”
Mitä ihmettä tuo on?
sisustusarkkitehti suunnittelu kuvio putoaa rakenne-luokka, joka käsittelee todellista rakennetta luokkaa, onko perintönä, koostumus tai molemmat. Tämän suunnittelun tavoitteena on muokata esineiden toiminnallisuutta ajanhetkellä. Tämä on yksi monista muista suunnittelumalleista, jotka hyödyntävät abstrakteja luokkia ja rajapintoja koostumuksen kanssa saadakseen haluamansa tuloksen.,
Let ’ s give Math a chance (shudder?) tuoda tämä kaikki perspektiiviin;
ota 4 kahvisekoitusta ja 10 lisäosaa. Jos me kiinni sukupolven alaluokkien kunkin eri yhdistelmä kaikki lisäosat yhden tyypin kahvia. Se on;
(10-1)2 = 92 = 81 alaluokkien
– Emme vähennä 1 10, koska et voi yhdistää yksi add-on toinen samaa tyyppiä, sokerilla kuulostaa tyhmältä. Ja se on vain yhdelle kahvisekoitukselle. Kerrotaan, että 81 4 ja saat huimat 324 eri alaluokkaan!, Puhu kaikesta siitä, että koodaus …
, mutta sisustuskuviolla tarvitaan tässä skenaariossa vain 16 luokkaa. Lyödäänkö vetoa?
Jos me kartoittaa meidän skenaarion mukaan luokan kaavio, saamme 4 luokat 4 kahvisekoituksia, 10 jokaisen lisäosan ja 1 abstrakti komponentti ja 1 enemmän abstrakti sisustaja. Katso! 16!, Anna nyt se 100 dollaria.?? (jk, mutta sitä ei voida evätä, jos annetaan… vain sanoa)
Kuten voitte nähdä edellä, aivan kuten betoni kahvin sekoituksia ovat alaluokkien juoma abstrakti luokka, AddOn abstrakti luokka, joka myös perii sen menetelmät siitä. Lisäosat, jotka ovat sen alaluokkia, puolestaan perivät kaikki uudet menetelmät lisätä toimintoja perusobjektiin tarvittaessa.
Let ’ s get to coding, to see this pattern in use.,
Ensin tehdä Abstrakti juoma luokka, että kaikki eri kahvin sekoituksia perivät alkaen:
Sitten lisätä sekä betoni-kahvin sekoitus luokat.
AddOn abstract-Luokka periytyy myös Beverage abstract-luokasta (lisää tästä alla).
Ja nyt konkreettisia toteutuksia tämä abstrakti luokka:
Kuten näette edellä, voimme siirtää minkä tahansa alaluokka Juoma tahansa alaluokka AddOn, ja saada lisätty kustannukset sekä päivitetty kuvaus. Ja, koska AddOn luokka on pääosin tyypin Juoman, voimme välittää AddOn toiseen AddOn., Näin voimme lisätä minkä tahansa määrän lisäosia tiettyyn kahviseokseen.
nyt kirjoittaa jotain koodia testata tätä.
lopputulos on:
Se toimii! Meillä oli mahdollisuus lisätä enemmän kuin yksi add-on kahvi sekoitus ja onnistuneesti päivittää sen lopullinen hinta ja kuvaus, ilman tarvetta tehdä ääretön alaluokkien jokaisen lisäosan yhdistelmä kaikille kahvin sekoituksia.
lopulta viimeiseen kategoriaan.,
Tyyppi 3: Käyttäytymis – Komento-suunnittelumalli
behavioral design malli keskittyy siihen, miten luokat ja oliot kommunikoivat keskenään. Pääpaino komento kuvio on teroittaa korkeampi löysä kytkentä välillä osapuolten (lue: luokat).
Uhhhhh … What ’ s that?
kytkentä on tapa, jolla kaksi (tai useampi) luokkaa, jotka vuorovaikuttavat keskenään, hyvin, vuorovaikuttavat keskenään. Ideaaliskenaario näiden luokkien vuorovaikutuksessa on se, että ne eivät ole kovin riippuvaisia toisistaan. Se on irrallinen kytkentä., Niin, parempi määritelmä löysä kytkentä olisi, luokat, jotka ovat yhteydessä toisiinsa, jolloin vähiten käyttöä toisiinsa.
tämän kuvion tarve syntyi, kun pyyntöjä piti lähettää tietämättä tietoisesti, mitä pyydät tai kuka vastaanottaja on.
tässä kuviossa vetoamisluokka irrotetaan siitä luokasta, joka tosiasiallisesti suorittaa kanteen. Invoker-luokassa on vain callable method execute, joka suorittaa tarvittavan komennon, kun asiakas sitä pyytää.
otetaan todellinen perusesimerkki, jossa tilataan ateria hienosta ravintolasta., Kun virtaus menee, annat tilauksesi (komento) tarjoilija (manaaja), joka sitten luovuttaa sen kokki(vastaanotin), jotta saat ruokaa. Kuulostaa yksinkertaiselta, mutta koodaa vähän.
ajatus on melko yksinkertainen, mutta koodaus menee ympäri nenä.,
virtaus toiminnan tekninen puoli on, sinun on tehdä konkreettisia komento, joka toteuttaa Komennon käyttöliittymä, kysyy vastaanotin täydellinen toiminta, ja lähettää komennon invoker. Laskuttaja on henkilö, joka tietää milloin antaa tämän käskyn. Kokki on ainoa, joka tietää, mitä tehdä, kun annetaan erityinen käsky / käsky., Joten, kun suorittaa menetelmä invoker on ajaa, se puolestaan aiheuttaa sen, että komento-objektit’ execute menetelmä toimimaan vastaanotin, näin täyttämällä tarvittavat toimet.,
Mitä meidän täytyy toteuttaa on;
- käyttöliittymä-Komento
- luokka, Järjestys, joka toteuttaa Komennon käyttöliittymä
- luokka, Tarjoilija (manaaja)
- luokan Kokki (vastaanotin)
Niin, koodaus menee näin:
Kokki, vastaanotin
Komento, käyttöliittymä
public interface Command {public abstract void execute();}Tilata, betoni-komento
Tarjoilija, invoker
public class Waiter {private Order order;public Waiter(Order ord) {this.order = ord;}public void execute() {this.order.execute();}}Voit, asiakas
Kuten näette edellä, Asiakas tekee Tilauksen ja asettaa Vastaanottimen kuin Kokki., Tilaus lähetetään tarjoilijalle, joka tietää, milloin tilaus suoritetaan (eli milloin antaa kokille käsky kokata). Kun laskuttaja suoritetaan, käskyn toteutustapa suoritetaan vastaanottimella (eli kokki saa käskyn joko keittää pastaa ? tai leipoa kakkua?).,
Nopea kertaus
tämän jälkeen kävimme läpi:
- Mitä on suunnittelumalli todella on,
- erilaisia suunnittelumalleja ja miksi ne ovat eri
- Yksi perus-tai yhteinen suunnittelu kuvio kunkin
toivottavasti tästä oli apua.
Etsi Postille koodi repo, täältä.