Programiranje

Uvod v oblikovalske vzorce, 1. del: Zgodovina in klasifikacija vzorčnih vzorcev

Razvite so bile številne strategije za poenostavitev in zmanjšanje stroškov oblikovanja programske opreme, zlasti na področju vzdrževanja. Učenje prepoznavanja in dela s programsko opremo za večkratno uporabo (občasno imenovano programska integrirana vezja) je ena od strategij. Druga uporaba je oblikovalskih vzorcev.

Ta članek predstavlja tridelno serijo o vzorcih oblikovanja. V tem delu bom predstavil konceptualni okvir oblikovalskih vzorcev in si ogledal predstavitev ocenjevanja vzorčnega vzorca za določen primer uporabe. Prav tako bom razpravljal o zgodovini oblikovalskih vzorcev in anti-vzorcev. Na koncu bom razvrstil in povzel najpogosteje uporabljene vzorce oblikovanja programske opreme, ki so bili odkriti in dokumentirani v zadnjih nekaj desetletjih.

Kaj je oblikovalski vzorec?

Oblikovanje objektno usmerjene programske opreme za večkratno uporabo, ki modelira obstoječi sistem, je resnično zahtevno. Razvijalec programske opreme mora sistemske entitete razdeliti na razrede, katerih javni vmesniki niso pretirano zapleteni, vzpostaviti odnose med razredi, izpostaviti hierarhije dedovanja in še več. Ker večina programske opreme ostaja v uporabi še dolgo potem, ko je bila napisana, morajo razvijalci programske opreme upoštevati tudi trenutne zahteve aplikacij, hkrati pa ohraniti svojo kodo in infrastrukturo dovolj prožne, da ustrezajo prihodnjim potrebam.

Izkušeni objektno usmerjeni razvijalci so odkrili, da vzorci oblikovanja programske opreme olajšajo kodiranje stabilnih in robustnih programskih sistemov. Ponovna uporaba teh vzorcev namesto nenehnega razvijanja novih rešitev iz nič je učinkovita in zmanjšuje tveganje za napake. Vsak vzorec načrtovanja identificira ponavljajoči se problem načrtovanja v določenem kontekstu aplikacije, nato pa ponudi splošno rešitev za večkratno uporabo, ki velja za različne scenarije aplikacije.

"A oblikovalski vzorec opisuje razrede in interaktivne predmete, ki se uporabljajo za reševanje splošnega problema oblikovanja v določenem kontekstu. "

Nekateri razvijalci definirajo a oblikovalski vzorec kot entiteta, kodirana z razredom (na primer povezan seznam ali bitni vektor), medtem ko drugi pravijo, da je vzorec načrtovanja v celotni aplikaciji ali podsistemu. Moje mnenje je, da a oblikovalski vzorec opisuje razrede in interaktivne predmete, ki se uporabljajo za reševanje splošnega problema oblikovanja v določenem kontekstu. Bolj formalno je oblikovalski vzorec določen kot opis, ki je sestavljen iz štirih osnovnih elementov:

  1. A ime ki opisuje oblikovalski vzorec in nam daje besednjak za razpravo o njem
  2. A problem ki opredeljuje problem oblikovanja, ki ga je treba rešiti, skupaj s kontekstom, v katerem se težava pojavlja
  3. A rešitev k problemu, ki bi (v kontekstu vzorca programske opreme) moral identificirati razrede in predmete, ki prispevajo k oblikovanju, skupaj z njihovimi odnosi in drugimi dejavniki
  4. Razlaga posledice uporabe vzorčnega vzorca

Če želite določiti ustrezen vzorec oblikovanja, ki ga želite uporabiti, morate najprej jasno prepoznati težavo, ki jo želite rešiti; tam je problem element opisa vzorčnega vzorca je koristen. Izbira enega vzorca oblikovanja pred drugim običajno vključuje tudi kompromise, ki lahko vplivajo na prilagodljivost aplikacije ali sistema in prihodnje vzdrževanje. Zato je pomembno razumeti posledice uporabe določenega vzorčnega vzorca, preden ga začnete izvajati.

Ocenjevanje vzorca oblikovanja

Razmislite o nalogi oblikovanja zapletenega uporabniškega vmesnika z gumbi, besedilnimi polji in drugimi komponentami, ki niso v vsebniku. Vzorec sestavljenega oblikovanja obravnava posode kot sestavne dele, kar nam omogoča, da posode in njihove sestavne dele (posode in nekontejnerje) ugnezdimo v druge zabojnike, in to rekurzivno. Če bi se odločili, da ne bomo uporabili sestavljenega vzorca, bi morali ustvariti veliko specializiranih komponent, ki niso vsebniki (na primer ena komponenta, ki združuje besedilno polje gesla in gumb za prijavo), kar je težje doseči.

Ko smo to premislili, razumemo težavo, ki jo skušamo rešiti, in rešitev, ki jo ponuja sestavljeni vzorec. Kakšne pa so posledice uporabe tega vzorca?

Uporaba sestavljenega pomeni, da bodo vaše hierarhije razredov mešale komponente vsebnika in vsebnika. Preprostejše stranke bodo z vsebniki in nekontejnerskimi komponentami ravnale enotno. In lažje bo uvesti nove vrste komponent v uporabniški vmesnik. Sestavljeni lahko vodijo tudi do preveč posplošeno zasnove, zaradi česar je težje omejiti vrste komponent, ki jih je mogoče dodati v posodo. Ker se za uveljavitev omejitev tipa ne boste mogli zanašati na prevajalnik, boste morali uporabiti preverjanja vrste izvajanja.

Kaj je narobe s preverjanjem vrste izvajanja?

Vključujejo preverjanja vrste izvajanja če izjave in instanceof operater, kar vodi do krhke kode. Če pozabite posodobiti preverjanje vrste izvajalnega okolja, ko se zahteve za aplikacije razvijajo, lahko naknadno uvedete napake.

Prav tako je mogoče izbrati ustrezen vzorec oblikovanja in ga uporabiti nepravilno. The Dvakrat preverjeno zaklepanje vzorec je klasičen primer. Dvojno preverjeno zaklepanje zmanjša stroške prevzema ključavnice tako, da najprej preizkusite merilo zaklepanja, ne da bi dejansko pridobili ključavnico, nato pa ključavnico pridobite le, če preverjanje pokaže, da je zaklepanje potrebno. Čeprav je bilo na papirju videti dobro, je dvojno preverjeno zaklepanje v JDK 1.4 imelo nekaj skritih zapletenosti. Ko je JDK 5 razširil semantiko hlapljivo ključna beseda, razvijalci so končno lahko izkoristili prednosti dvojno preverjenega vzorca zaklepanja.

Več o dvojno preverjenem zaklepanju

Glejte "Dvakrat preverjeno zaklepanje: pametno, a pokvarjeno" in "Ali je mogoče dvojno preverjeno zaklepanje popraviti?" (Brian Goetz, JavaWorld), če želite izvedeti več o tem, zakaj ta vzorec ni deloval v JDK 1.4 in starejših. Če želite več informacij o določanju DCL v JDK 5 in novejših različicah, glejte "Izjava o dvojnem preverjanju zaklepanja je prekinjena" (Oddelek za računalništvo na Univerzi v Marylandu, David Bacon in drugi).

Proti vzorci

Kadar se oblikovalski vzorec pogosto uporablja, vendar je neučinkovit in / ali kontraproduktiven, je vzorčni vzorec znan kot anti-vzorec. Lahko bi trdili, da je bilo dvojno preverjeno zaklepanje, kot je bilo uporabljeno v JDK 1.4 in prej, proti vzorcu. Rekel bi, da je bila v tem kontekstu zgolj slaba ideja. Da bi se slaba ideja razvila v vzorec, morajo biti izpolnjeni naslednji pogoji (glejte Viri).

  • Ponavljajoči se vzorec delovanja, procesa ali strukture, ki se sprva zdi koristen, vendar na koncu povzroči več slabih posledic kot koristnih rezultatov.
  • Obstaja alternativna rešitev, ki je jasno dokumentirana, dokazana v praksi in ponovljiva.

Čeprav je dvojno preverjeno zaklepanje v JDK 1.4 izpolnilo prvo zahtevo proti vzorcu, ni izpolnilo druge: čeprav lahko uporabite sinhronizirano da bi rešili problem lene inicializacije v večnitnem okolju, bi s tem sploh premagali razlog za uporabo dvojno preverjenega zaklepanja.

Zastoji proti vzorcem

Prepoznavanje vzorcev je predpogoj, da se jim izognemo. V treh delih Obi Ezechukwuja si preberite uvod v tri proti vzorce, ki slovijo po zastoju:

  • Brez arbitraže
  • Združevanje delavcev
  • Inkrementalno zaklepanje

Zgodovina oblikovalskih vzorcev

Oblikovalski vzorci segajo v konec sedemdesetih let z objavo Vzorčni jezik: mesta, zgradbe, gradnja arhitekta Christopherja Alexandra in nekaj drugih. Ta knjiga je predstavila oblikovalske vzorce v arhitekturnem kontekstu in predstavila 253 vzorcev, ki so skupaj tvorili tisto, kar so avtorji poimenovali a jezik vzorcev.

Ironija oblikovalskih vzorcev

Čeprav vzorci oblikovanja, uporabljeni za načrtovanje programske opreme, sledijo njihovemu začetku Vzorčni jezik, na to arhitekturno delo je vplival takrat nastajajoči jezik za opisovanje računalniškega programiranja in oblikovanja.

Koncept jezika vzorcev se je kasneje pojavil pri Donaldu Normanu in Stephenu Draperju Oblikovanje sistema, ki ga osredotoča uporabnik, ki je bila objavljena leta 1986. Ta knjiga predlaga uporabo jezikov vzorcev za oblikovanje interakcij, kar je praksa oblikovanja interaktivnih digitalnih izdelkov, okolij, sistemov in storitev za človeško uporabo.

Medtem sta Kent Beck in Ward Cunningham začela preučevati vzorce in njihovo uporabnost pri oblikovanju programske opreme. Leta 1987 so uporabili vrsto oblikovalskih vzorcev, da bi pomagali Tektronixovi skupini Semiconductor Test Systems Group, ki je imela težave z dokončanjem projektnega projekta. Beck in Cunningham sta upoštevala Aleksandrov nasvet za oblikovanje, ki je usmerjeno na uporabnika (omogočanje predstavnikom uporabnikov projekta, da določijo izid oblikovanja), hkrati pa sta jim tudi olajšala delo.

Erich Gamma je med delom na doktorski disertaciji spoznal tudi pomen ponavljajočih se vzorcev oblikovanja. Verjel je, da lahko vzorci oblikovanja olajšajo pisanje predmetno usmerjene programske opreme za večkratno uporabo, in razmišljal, kako jih učinkovito dokumentirati in sporočiti. Pred Evropsko konferenco o objektno usmerjenem programiranju leta 1991 sta Gamma in Richard Helm začela katalogizirati vzorce.

Na delavnici OOPSLA, ki je potekala leta 1991, sta se Gammi in Helmu pridružila Ralph Johnson in John Vlissides. To Tolpa štirih (GoF), kot so bili pozneje znani, je nadaljeval s pisanjem popularnega Vzorci oblikovanja: elementi predmetno usmerjene programske opreme za večkratno uporabo, ki dokumentira 23 vzorcev oblikovanja v treh kategorijah.

Sodobni razvoj oblikovalskih vzorcev

Oblikovalski vzorci se še naprej razvijajo od prvotne knjige GoF, zlasti ker so se razvijalci programske opreme soočali z novimi izzivi, povezanimi s spreminjanjem zahtev glede strojne opreme in aplikacij.

Leta 1994 je bila ustanovljena neprofitna organizacija s sedežem v ZDA, znana kot Hillside Group Vzorčni jeziki programov, skupina letnih konferenc, katerih cilj je razviti in izboljšati umetnost vzorcev oblikovanja programske opreme. Te tekoče konference so dale številne primere vzorcev oblikovanja, specifičnih za posamezno področje. Na primer, oblikujte vzorce v sočasnem kontekstu.

Christopher Alexander na OOPSLA

Osrednji nagovor OOPSLA 96 je imel arhitekt Christopher Alexander, ki je razmišljal o svojem delu in o tem, kako je objektno usmerjena programska skupnost dosegla in zgrešila cilj pri sprejemanju in prilagajanju svojih idej o vzorčnih jezikih programski opremi. Aleksandrov nagovor si lahko preberete v celoti: "Izvori teorije vzorcev: prihodnost teorije in generacija živega sveta."

Leta 1998 je Mark Grand izšel Vzorci v Javi. Ta knjiga je vključevala vzorce oblikovanja, ki jih ni mogoče najti v knjigi GoF, vključno z vzorci sočasnosti. Grand je uporabil tudi Unified Modeling Language (UML) za opis vzorcev oblikovanja in njihovih rešitev. Primeri knjige so bili izraženi in opisani v jeziku Java.

Vzorci oblikovanja programske opreme po klasifikaciji

Sodobni vzorci oblikovanja programske opreme so na splošno razvrščeni v štiri kategorije glede na njihovo uporabo: kreativni, strukturni, vedenjski in sočasni. Razpravljal bom o vsaki kategoriji, nato pa našteval in opisal nekatere vidne vzorce za vsako.

Druge vrste vzorčnih vzorcev

Če mislite, da obstaja več vrst vzorcev, imate prav. Kasneje v tej seriji bomo razpravljali o dodatnih vrstah vzorčnih vzorcev: interakcija, arhitekturni, organizacijski in komunikacijski / predstavitveni vzorci.

Ustvarjalni vzorci

A kreativni vzorec abstrahira postopek instanciranja in loči, kako so predmeti ustvarjeni, sestavljeni in predstavljeni od kode, ki se nanje opira. Razredni kreativni vzorci uporabite dedovanje za spreminjanje razredov, ki so ustvarjeni, in predmetni kreativni vzorci delegiranje instanciranja drugim objektom.

  • Abstraktna tovarna: Ta vzorec ponuja vmesnik za vključitev skupine posameznih tovarn, ki imajo skupno temo, ne da bi določili njihove konkretne razrede.
  • Graditelj: Ločuje gradnjo kompleksnega predmeta od njegove predstavitve, kar omogoča isti postopek gradnje za ustvarjanje različnih predstavitev. Abstrahiranje korakov gradnje objektov omogoča različne izvedbe korakov za izdelavo različnih predstavitev predmetov.
  • Tovarniška metoda: Določi vmesnik za ustvarjanje predmeta, vendar omogoča podrazredom, da se odločijo, kateri razred bodo ustvarili. Ta vzorec razredu omogoča odložitev instanciranja na podrazrede. Vbrizgavanje odvisnosti je povezan vzorec. (Glej vire.)
  • Lena inicializacija: Ta vzorec nam omogoča, da odložimo ustvarjanje predmetov, iskanje zbirke podatkov ali drug drag postopek, dokler rezultat ni prvič potreben.
  • Multiton: Razširi koncept singleton za upravljanje zemljevida imenovanih primerkov razreda kot parov ključ-vrednost in nudi globalno točko dostopa do njih.
  • Območje predmetov: Nabor inicializiranih predmetov naj bo pripravljen za uporabo, namesto da bi jih dodelili in uničili na zahtevo. Namen je preprečiti drago pridobivanje in predelavo virov z recikliranjem predmetov, ki niso več v uporabi.
  • Prototip: Določa vrste predmetov, ki jih želite ustvariti s prototipskim primerkom, nato pa ustvarite nove predmete s kopiranjem tega prototipa. Prototipni primerek je kloniran za ustvarjanje novih predmetov.
  • Pridobivanje virov je inicializacija: Ta vzorec zagotavlja, da se viri samodejno in pravilno inicializirajo in ponovno pridobijo, tako da jih vežejo na življenjsko dobo ustreznih predmetov. Viri se pridobijo med inicializacijo predmetov, ko ni možnosti, da bi jih uporabili, preden so na voljo, in se sprostijo z uničenjem istih predmetov, kar je zagotovljeno tudi v primeru napak.
  • Singleton: Zagotavlja, da ima razred samo en primerek in zagotavlja globalno točko dostopa do tega primerka.
$config[zx-auto] not found$config[zx-overlay] not found