OppikirjojaWeb ja WordPressWeb-suunnitteluWeb-vinkkejä ja -vinkkejä

Suunnittelumalleja aloittelijoille

Viimeisin päivitys kesä 8, 2023

Jos olet jo kirjoittanut ohjelmia suurille/pienille tuotteille tai ohjelmistosovelluksille, olet todennäköisesti käyttänyt paljon suunnittelukuvioita… vaikka on mahdollista, että ne eivät ehkä ole yksi käytetyimmistä / vakiomuotoilumalleista.

Mutta kyllä, suunnittelumallin toteuttamisen ja suunnittelumallin ”käyttämisen” välillä on selvä ero… joko suunnittelukuvioiden parissa työskentelevä henkilö ymmärtää sen tai ymmärtää sen helposti.

Asia on siinä, että suunnittelumallit eivät ole uusia ohjelmoijille.

Tässä alla olevassa artikkelissa yritän selittää suunnittelumalleja sen perusteissa, ja tutkimme eri kuvioiden yksityiskohtia, esimerkkejä jne. toisessa artikkelissa.

Mikä on suunnittelumalli?

Aloittaa…

Mielestäni paras tapa aloittaa suunnittelumallien ymmärtäminen on ymmärtää ei-teknisiä malleja, joita me tietoisesti/tietämättä seuraamme jokapäiväisessä elämässämme.

Otetaan esimerkiksi paljon avoimeen työpaikkaan lähetettyjä ansioluetteloita. Kaikkien ansioluettelo ei näytä samalta… vaikka heillä kaikilla on tapana tehdä sama asia, eli kertoa lukijalle, mitä he ovat taitaneet tai kuinka hän voi soveltua työhön.

Suurin osa heistä, jotka lähettävät ansioluettelonsa töihin, tietävät, että heidän on lähetettävä ansioluettelo, jossa on tietty tietojoukko muotoillussa Word-asiakirjassa.

Tämä… on malli, että jokainen lähettää ansioluettelon, jossa on tietty tietojoukko.

Jos sinusta tuntuu… kutsu sitä malleiksi kuvioiden sijaan. Suunnittelumallit.

Oikeassa elämässä on monia sellaisia asioita, jotka ovat malleja. Jotkut ihmiset pitävät alla olevista esimerkeistä:

Kaikki kokit ympäri maailmaa valmistavat pizzaa tai ranskalaisia perunoita samalla tavalla. Vaikka ne voivat lisätä sen / maustaa sen eri tavalla. Se on malli.

Jokaisen auton suunnittelu noudattaa perussuunnittelumallia, neljä pyörää, ohjauspyörä, ydinvoimajärjestelmä, kuten kaasupoljin-jarru-kytkin jne.

Kaikki toistuvasti rakennetut / tuotetut asiat noudattavat väistämättä malliaan suunnittelussaan… olipa kyseessä sitten autot, pizzat, pankkiautomaatit, mikä tahansa… jopa hammasharja.

Suunnitteluista, joista on melkein tullut standardi tapa koodata joitain logiikkaa/mekanismia/tekniikkaa ohjelmistoissa, on siksi tullut tunnetuksi – ja siksi niitä tutkitaan nimellä Software Design Patterns.

Содержание показать

Miksi suunnittelumalli on tärkeä?

Periaatteessa kahdesta syystä:

Pitää kiinni standardista
Kehityksen vauhdittamiseksi

Selitän yksityiskohtaisesti.

Ensinnäkin näemme, miksi vakiokuvion pitäminen on mielenkiintoista.

Otetaan esimerkki luettelo ansioluetteloista, joista keskustelimme aiemmin.

Saattaa olla yksi tai kaksi hakijaa, jotka lähettävät työhakemuksensa sähköpostitekstinä ilman asianmukaista muotoilua, ilman liitteitä sähköpostiinsa jne., .. nämä yksi tai kaksi hakijaa eivät noudata kaavaa.. eivätkä todennäköisesti päädy työn kanssa…. miksi? Koska he poikkeavat vakiintuneesta mallista, mikä ei ehkä pidä työpaikan ansioluetteloiden listaajista.

Eikö ole ketään, joka poikkeaa mallista ja tulee ”cooliksi”? Eikö se ole innovaatiota?

Kyllä, joskus hyvin eri tavalla esitetty ansioluettelo saa työpaikan, koska se on erilainen kuin muut. Yleensä olen kuullut web-suunnittelijoista, jotka päätyivät parhaisiin töihin, koska he kokosivat ja esittelivät työstään CD-elokuvan tai tekivät työtään selittävän animaatiohahmon, olivat laittaneet sen blogiinsa ja niin edelleen.

Mutta… tämä on kokeilua (Innovaatio tulee onnistuneista kokeiluista).

Useimmiten ohjelmistokehityksessä ei ole varaa kokeilla aikajanapaineen, odotusten jne. takia, mutta kyllä, joskus mielenkiintoiset projektit mahdollistavat kokeilun.

Ohjelmistoissa emme voi tehdä perusasioita, kuten pankkitalletusta… 101:llä tavalla… pankkitalletusta voi käsitellä vain muutamalla tavalla. joten on järkevää noudattaa vakiintunutta ja testattua mallia.

Useimmissa suunnittelukuvioissa on myös muunnelmia… jotkut muunnelmat ovat niin suosittuja, että muunnelmat ovat myös uusi vakiotyyppinen kuvio.

Ohjelmistoprojektien näinä päivinä odotetaan (ainakin implisiittisesti) seuraavan markkinoilla olevan samanlaisen tuotteen/ohjelmiston jo vakiintunutta suunnittelua.

Tässä tavanomaiseen koodaus- tai suunnittelumalliin kiinni pitäminen auttaa ohjelmistokehitystä… vauhdittamaan kehitystä, poistamaan ylimääräisiä kustannuksia, joita aiheutuu uudesta testaamattomasta toteutuksesta jne.

Kehitysajan kiinnittäminen

Vakiosuunnittelumallin noudattamisella on myös se etu, että se kommunikoi helposti ohjelmistoarkkitehtien, moduulijohtojen, tiimijohtajien, kehittäjien jne. puun/hierarkian kautta ”miten” jotain pitää kehittää, eikä vain ”mitä” on oltava kehitetty.

Joskus se jopa auttaa testaustiimejä, koska testaajat tietäisivät kokemuksesta, että tiettyä suunnittelumallia noudattava koodi voidaan todennäköisesti testata tietyllä tavalla testaustyökaluilla tietyn ajan kuluessa, eikä tällaisissa tunnetuissa malleissa ehkä ole joitakin puutteita. tai niissä on ”tunnettuja” puutteita.

Eikö suunnittelukuvioiden käyttäminen anna persoonallisuutta?

Ei. Ensinnäkin, koska emme tarkoita, että noudatat suunnittelumallia ja mitään muuta ei tapahdu. Useimmat projektitoteutukset jakavat vain perusvaatimukset muiden projektien kanssa, ja niissä on todennäköisesti poikkeamia. Näiden poikkeamien rakentaminen vaatii toteutuksessa käytettyjen standardimallien taipumista ja venyttämistä.

Se on kuin pizzan tekeminen tavallisella tavalla, sitten sen maustaminen / esittäminen erilaisille vaatimuksille, joko täyteen piirakkapizzaan tai leikattu piirakka tai mitä tahansa.

Suunnittelumallien tärkeyden ymmärtämisessä yksi asia on hyvintärkeä :

Suunnittelumallit eivät ole mitään tekniikkaa tai kehystä, jota tietty yritys tai ohjelmointikieli pakottaa meihin. Tämä tarkoittaa, että se on kuin avoin käsite. Voit vapaasti ottaa sen, käyttää sitä, muokata sitä tarpeidesi mukaan ja mikä tärkeintä… tuntea sen omaksesi.

Kaikki tavalliset tai suositut suunnittelumallit ovat itse asiassa laajennettavissa melko voimakkaasti.. niistä tuli suosittuja ensinnäkin vain siksi, että monet ihmiset käyttävät sitä.. ja monet ihmiset käyttävät sitä vain siksi, että ne ovat joustavia omien vaatimustensa mukaan.

Tai kuinka arvelet, että vakiomuotoilumalli sopisi projektiin New Jerseyssä yritykselle ja myös Bangaloressa eri yritykselle ja erilaiselle projektille.

Tämä vie meidät ” Useimmat suunnittelumallit ovat yleisiä ”… eli niitä ei aina käytetä samantyyppisten ohjelmistojen rakentamiseen. Et ehkä kuule yleisissä keskusteluissa käytettyjä asioita, kuten ”pankkiohjelmistojen suunnittelumalli” tai ”sosiaalisen verkostoitumisen ohjelmistosuunnittelumalli”, vaan vain ”suunnittelukuvioita”.

Kenen pitäisi olla huolissaan suunnittelukuvioista?

Aivan kuten hyvä rakennusarkkitehti kasvattaa taitojaan rakennusten suunnittelussa, opiskelemalla lukuisten rakennusten ja muotojen arkkitehtuuria ja suunnittelua elämänsä aikana, ohjelmistoarkkitehdin tulisi tutkia ja visualisoida, kuinka eri ohjelmisto-/teknologiajärjestelmät eri puolilla maailmaa suunnitellaan tai suunnitellaan. arkkitehti.
Ja aivan kuten rakennuksen rakentajien tulisi olla tietoisia erilaisista tavoista toteuttaa rakennussuunnitelma joko omasta kokemuksestaan tai rakennuksen arkkitehdin ymmärtämällä.

Ohjelmistokehittäjien/ohjelmoijien tulee ymmärtää ohjelmistojen suunnittelun perusmallit ja niiden toteutuskoodit… joko itse tai ohjelmistoarkkitehti, joka neuvoo tiimiä kehittämään sen tietyn mallin mukaan.

Peruskoodimallit

Tämän artikkelin aloitusriveissä sanoin, että kuka tahansa ohjelmoija olisi käyttänyt suunnittelumalleja. Tässä on joitain hyvin yksinkertaisia esimerkkejä koodista, joka seuraa mallia.

Seuraavassa on Intercepting Filter -suunnittelumalli.
Piilota Kopioi koodi

switch (condition){
     case Value1:
     case Value2:
     default:
}

Tapahtumalaukaisimet, tapahtumakäsittelijät… kuuluvat Subject-Observer- perussuunnittelumalliin. Keskustelemme kunkin mallin standardeista, suosituista muunnelmista esimerkein… pian.
Jos olet käyttänyt jonkinlaisia kokoelmia, kuten Arraylist C#:ssa, ja iteroinut taulukon läpi, olet käyttänyt Iteratorin perussuunnittelumallia .
Alla oleva koodi on esimerkki poikkeusten käsittelyn / vastuun ketjun perusmallista .
Piilota Kopioi koodi
```
try{
}catch(Exception ex){
}
finally{
}
```

Suunnittelukuvioiden eri alueet

Ohjelmistoissa on erilaisia terminologioita kuin Design Patterns.. osa niistä liittyy usein suunnittelumalleihin, joista olemme tähän mennessä keskustelleet.. ja osa niistä ei liity täysin toisiinsa.

Sitä, mitä olemme tähän mennessä keskustelleet yllä, kutsutaan joskus ” toteutussuunnittelukuviksi ”.

On muitakin, kuten arkkitehtuurimalleja, puitemalleja, kielimalleja (jota enimmäkseen kutsutaan kielirakenteiksi).

Ne ovat eri tasoille asetettuja malleja… kuten Kielimallit ovat kaavoja, jotka on toteutettu osana ohjelmointikieliä, kuten C# / Java, kielen ominaisuuksina / rakenteina.. osan niistä olemme jo nähneet.

Kaikki yllä olevat esimerkit subjekti-tarkkailijasta, sieppaussuodattimesta jne. ovat kielirakenteita kaikissa suosituissa korkean tason ohjelmointikielissä, jotka tulivat C:n jälkeen.

Arkkitehtuurimallit ovat ohjelmistoarkkitehtuurin vakiomalleja, jotka yleensä viittaavat erilaisiin moduulien tai kerrosten tai tasojen sijoittamisen tai linkittämisen eri menetelmiin, jotka muodostavat koko sovelluksen.

Tämä ei mitenkään liity suunnittelumalleihin koodauksen/ohjelmoinnin merkityksessä, mutta niillä on samat vastaukset miksi/mitä on tässä artikkelissa käsitelty.

Kehysmallit eivät myöskään liity keskusteluun suunnittelumalleista. Kun .NET:n kaltaiset puitteet toteuttavat erityisiä keinoja kirjaamaan virheitä tai jäljittämään koodin suoritusreittejä helposti kehyksen sisäänrakennettujen menetelmien tai objektien kautta, tällaisia mekanismeja kutsutaan Framework-malleiksi.

Joitakin .NET Frameworkin esimerkkejä ovat stackTrace-ominaisuus, luokkaattribuuttiominaisuus, jossa on []-hakasulkeet luokka-/menetelmämääritelmien päällä jne.. Tällaisia ominaisuuksia käytettäessä koodaamme Frameworkin sisäänrakennetuilla malleilla.

Toivon, että tämä artikkeli auttaa tarjoamaan yleiskatsauksen suunnittelumalleista ja niihin liittyvistä terminologioista.

Toistaiseksi olemme keskustelleet vain siitä, mitä standardit ovat ja kuinka tärkeitä ne ovat.. mutta emme keskustelleet siitä, mitä standardimallit itse ovat.

Lisenssi

Tämä artikkeli, kaikki siihen liittyvät lähdekoodit ja tiedostot, on lisensoitu The Code Project Open License (CPOL) -lisenssillä.

: instantshift.com