Buvo sukurta daugybė strategijų, skirtų supaprastinti ir sumažinti programinės įrangos projektavimo išlaidas, ypač priežiūros srityje. Sužinokite, kaip atpažinti ir naudoti daugkartinio naudojimo programinės įrangos komponentus (kartais vadinamus programinės įrangos integriniai grandynai) yra viena strategija. Dizaino modelių naudojimas yra dar vienas.
Šiuo straipsniu pradedama trijų dalių dizaino modelių serija. Šioje dalyje supažindinsiu su konceptualia dizaino modelių sistema ir apžvelgsiu konkretaus naudojimo atvejo dizaino modelio įvertinimą. Aptarsiu ir dizaino modelių istoriją, ir antimalius modelius. Galiausiai suskirstysiu ir apibendrinsiu dažniausiai naudojamus programinės įrangos projektavimo modelius, kurie buvo atrasti ir dokumentuoti per pastaruosius porą dešimtmečių.
Kas yra dizaino modelis?
Sukurti daugkartinio naudojimo objektui skirtą programinę įrangą, kuri modeliuoja esamą sistemą, yra tikrai sudėtinga. Programinės įrangos kūrėjas turi suskirstyti sistemos objektus į klases, kurių viešosios sąsajos nėra pernelyg sudėtingos, užmegzti ryšius tarp klasių, atskleisti paveldėjimo hierarchijas ir kt. Kadangi dauguma programinės įrangos lieka naudojama dar ilgai po jos parašymo, programinės įrangos kūrėjai taip pat turi atsižvelgti į dabartinius programų reikalavimus, išlaikydami savo kodą ir infrastruktūrą pakankamai lanksčią, kad atitiktų būsimus poreikius.
Patyrę į objektą orientuoti kūrėjai atrado, kad programinės įrangos projektavimo modeliai palengvina stabilių ir tvirtų programinės įrangos sistemų kodavimą. Efektyvu pakartotinai naudoti šiuos dizaino modelius, o ne nuolat kurti naujus sprendimus nuo nulio, ir tai sumažina dalį klaidų rizikos. Kiekvienas dizaino modelis identifikuoja pasikartojančią dizaino problemą konkrečiame programos kontekste, tada siūlo apibendrintą, daugkartinio naudojimo sprendimą, taikomą skirtingiems taikymo scenarijams.
„A dizaino modelis apibūdina klases ir sąveikaujančius objektus, naudojamus sprendžiant bendrą dizaino problemą konkrečiame kontekste. "
Kai kurie kūrėjai apibrėžia a dizaino modelis kaip klasės užkoduotas objektas (pvz., susietas sąrašas ar bitų vektorius), o kiti sako, kad dizaino modelis yra visoje programoje ar posistemyje. Mano nuomone, a dizaino modelis aprašomos klasės ir sąveikaujantys objektai, naudojami sprendžiant bendrą dizaino problemą konkrečiame kontekste. Formaliau, dizaino modelis nurodomas kaip aprašymas, kurį sudaro keturi pagrindiniai elementai:
- A vardas tai apibūdina dizaino modelį ir suteikia mums žodyną apie jo aptarimą
- A problema kad identifikuojama projektavimo problema, kurią reikia išspręsti, kartu su kontekstu, kuriame problema kyla
- A sprendimas problemą, kuri (programinės įrangos dizaino modelio kontekste) turėtų nustatyti klases ir objektus, kurie prisideda prie dizaino, taip pat jų santykius ir kitus veiksnius
- Aiškinimas padarinius naudoti dizaino modelį
Norėdami nustatyti tinkamą dizaino modelį, pirmiausia turite aiškiai nustatyti problemą, kurią bandote išspręsti; tai kur problema naudingas dizaino modelio aprašymo elementas. Vieno dizaino modelio pasirinkimas, o ne kitas, taip pat paprastai apima kompromisus, kurie gali turėti įtakos programos ar sistemos lankstumui ir būsimai priežiūrai. Štai kodėl svarbu suprasti padarinius naudoti tam tikrą dizaino modelį prieš pradedant jį įgyvendinti.
Įvertinant dizaino modelį
Apsvarstykite užduotį sukurti sudėtingą vartotojo sąsają, naudojant mygtukus, teksto laukus ir kitus ne konteinerio komponentus. „Composite“ dizaino modelis konteinerius laiko komponentais, o tai leidžia konteinerius ir jų komponentus (konteinerius ir ne konteinerius) įdėti į kitus konteinerius ir tai daryti rekursiškai. Jei nuspręstume nenaudoti „Composite“ šablono, turėtume sukurti daug specializuotų komponentų, kurie nėra konteineriai (pvz., Vienas komponentas, sujungiantis slaptažodžio teksto lauką ir prisijungimo mygtuką), o tai pasiekti yra sunkiau.
Tai gerai apgalvoję suprantame problemą, kurią bandome išspręsti, ir sudėtinio modelio siūlomą sprendimą. Bet kokios yra šio modelio naudojimo pasekmės?
„Composite“ naudojimas reiškia, kad jūsų klasės hierarchijos maišys sudėtinius ir sudėtinius komponentus. Paprastesni klientai vienodai traktuos konteinerių ir ne konteinerių komponentus. Ir bus lengviau įvesti naujo tipo komponentus į vartotojo sąsają. Kompozitas taip pat gali sukelti pernelyg apibendrintas dizainas, todėl sunkiau apriboti komponentų, kuriuos galima pridėti į konteinerį, rūšis. Kadangi negalėsite pasikliauti kompiliatoriumi vykdydami tipo apribojimus, turėsite naudoti vykdymo laiko tipo patikrinimus.
Kas blogo vykdymo laiko tipo patikrinimuose?
Apima vykdymo laiko tipo patikrinimai jei pareiškimus ir egzempliorius operatorius, o tai lemia trapų kodą. Jei pamiršite atnaujinti vykdymo laiko tipo patikrą, kai keičiasi programos reikalavimai, vėliau galite įvesti klaidų.
Taip pat galima pasirinkti tinkamą dizaino modelį ir jį naudoti neteisingai. Dvigubai patikrintas užraktas modelis yra klasikinis pavyzdys. Dvigubai patikrintas užraktas sumažina užrakto įsigijimo pridėtines išlaidas, pirmiausia išbandydamas užrakto kriterijų, faktiškai neįgydamas užrakto, o tada įsigydamas užraktą tik tuo atveju, jei patikrinus nurodoma, kad reikia užrakinti. Nors popieriuje jis atrodė gerai, dvigubai patikrintas JDK 1.4 užrakinimas turėjo keletą paslėptų sudėtingumų. Kai JDK 5 išplėtė semantiką nepastovus raktinis žodis, kūrėjai pagaliau galėjo pasinaudoti dvigubai patikrinto užrakto modelio pranašumais.
Daugiau apie dvigubai patikrintą fiksavimą
Žr. „Dvigubai patikrintas užraktas: sumanus, bet sugedęs“ ir „Ar galima patikrinti dvigubai patikrintą užraktą?“ (Brian Goetz, JavaWorld), kad sužinotumėte daugiau, kodėl šis modelis neveikė JDK 1.4 ir ankstesnėse versijose. Norėdami sužinoti daugiau apie DCL nurodymą JDK 5 ir vėlesnėse versijose, žr. „Dukart patikrinta užraktas neveikia“ deklaraciją (Merilendo universiteto Kompiuterijos katedra, Davidas Baconas ir kt.).
Anti-modeliai
Kai dažniausiai naudojamas dizaino modelis, tačiau jis yra neveiksmingas ir (arba) neproduktyvus, dizaino modelis yra žinomas kaip antimodelis. Galima teigti, kad dvigubai patikrintas užraktas, naudojamas JDK 1.4 ir ankstesnėse versijose, buvo anti-modelis. Sakyčiau, kad tai buvo tik bloga idėja šiame kontekste. Kad bloga idėja virstų antimodeliu, turi būti įvykdytos šios sąlygos (žr. Ištekliai).
- Pakartotinis veikimo, proceso ar struktūros modelis, kuris iš pradžių atrodo naudingas, tačiau galiausiai sukelia daugiau blogų padarinių nei naudingų rezultatų.
- Egzistuoja alternatyvus sprendimas, kuris yra aiškiai dokumentuotas, įrodytas praktikoje ir pakartojamas.
Dvigubai patikrintas JDK 1.4 užraktas atitiko pirmąjį anti-modelio reikalavimą, tačiau jis neatitiko antrojo: nors jūs galėjote naudoti sinchronizuotas jei norite išspręsti tingaus inicializavimo problemą daugialypėje aplinkoje, tai būtų nugalėjusi dvigubo patikrinimo užrakto naudojimo priežastį.
Aklavietės anti-modeliai
Anti-modelių atpažinimas yra būtina sąlyga jų išvengti. Perskaitykite trijų dalių Obi Ezechukwu seriją, kurioje rasite įvadą į tris antimustrus, garsėjančius aklavietės sukėlimu:
- Jokio arbitražo
- Darbuotojų sujungimas
- Papildomas užraktas
Dizaino modelio istorija
Dizaino modeliai atsirado aštuntojo dešimtmečio pabaigoje, kai buvo paskelbta Rašto kalba: miestai, pastatai, statyba pateikė architektas Christopheris Aleksandras ir keletas kitų. Ši knyga pristatė dizaino modelius architektūriniame kontekste, pateikdama 253 modelius, kurie kartu suformavo tai, ką autoriai vadino a modelio kalba.
Dizaino raštų ironija
Nors programinės įrangos projektavimui naudojami dizaino modeliai rodo jų pradžią Rašto kalba, šiam architektūriniam darbui įtakos turėjo tada atsiradusi kalba, apibūdinanti kompiuterių programavimą ir dizainą.
Modelio kalbos samprata vėliau atsirado Donaldo Normano ir Stepheno Draperio Į vartotoją orientuotas sistemos dizainas, kuri buvo išleista 1986 m. Ši knyga pasiūlė pritaikyti šablonines kalbas sąveikos dizainas, tai yra interaktyvių skaitmeninių produktų, aplinkos, sistemų ir paslaugų projektavimo žmonėms praktika.
Tuo tarpu Kentas Beckas ir Wardas Cunninghamas pradėjo tirti modelius ir jų pritaikymą programinės įrangos projektavimui. 1987 m. Jie naudojo dizaino modelių seriją, kad padėtų „Tektronix“ puslaidininkių bandymo sistemų grupei, kuriai kilo problemų baigiant projekto projektą. Beckas ir Cunninghamas vadovavosi Aleksandro patarimais, susijusiais su į vartotoją orientuotu dizainu (leidžiant projekto vartotojų atstovams nustatyti dizaino rezultatus), taip pat pateikdami kai kuriuos dizaino modelius, kad būtų lengviau atlikti darbą.
Dirbdamas prie daktaro disertacijos Erichas Gamma taip pat suprato pasikartojančių dizaino modelių svarbą. Jis tikėjo, kad projektavimo modeliai gali palengvinti daugkartinio naudojimo objektui skirtos programinės įrangos rašymą ir svarstė, kaip juos veiksmingai dokumentuoti ir komunikuoti. Prieš 1991 m. Europos konferenciją apie objektinį programavimą Gamma ir Richardas Helmas pradėjo kurti modelius.
OOPSLA seminare, vykusiame 1991 m., Prie Gammos ir Helmo prisijungė Ralphas Johnsonas ir Johnas Vlissidesas. Tai Keturių gauja (GoF), kaip jie vėliau buvo žinomi, toliau rašė populiarųjį Dizaino modeliai: daugkartinio naudojimo objektų programinės įrangos elementai, kuriame dokumentuojami 23 dizaino modeliai trijose kategorijose.
Šiuolaikinė dizaino modelių raida
Dizaino modeliai ir toliau tobulėjo nuo originalios „GoF“ knygos, ypač todėl, kad programinės įrangos kūrėjai susidūrė su naujais iššūkiais, susijusiais su aparatūros ir programų reikalavimų keitimu.
1994 m. Įsteigta JAV įsikūrusi ne pelno organizacija, žinoma kaip „Hillside Group“ Programų kalbos, kasmetinių konferencijų grupė, kurios tikslas - plėtoti ir tobulinti programinės įrangos dizaino modelių meną. Šios vykstančios konferencijos davė daug specifinių sričių dizaino modelių pavyzdžių. Pavyzdžiui, dizaino modeliai lygiagretumo kontekste.
Christopheris Aleksandras OOPSLA
Pagrindinį OOPSLA 96 pranešimą skaitė architektas Christopheris Aleksandras. Aleksandras apmąstė savo darbą ir tai, kaip objektyviai orientuota programavimo bendruomenė pataikė ir praleido ženklą, priimdama ir pritaikydama savo idėjas apie šablonų kalbas programinei įrangai. Galite perskaityti visą Aleksandro kreipimąsi: „Rašto teorijos ištakos: teorijos ateitis ir gyvo pasaulio karta“.
1998 m. Markas Grandas išleistas Raštai „Java“. Ši knyga apėmė dizaino modelius, kurių nėra GoF knygoje, įskaitant sutapimo modelius. Grandas taip pat naudojo vieningą modeliavimo kalbą (UML), kad apibūdintų dizaino modelius ir jų sprendimus. Knygos pavyzdžiai buvo išreikšti ir aprašyti Java kalba.
Programinės įrangos projektavimo modeliai pagal klasifikaciją
Šiuolaikiniai programinės įrangos projektavimo modeliai iš esmės skirstomi į keturias kategorijas pagal jų naudojimą: kūrybos, struktūros, elgesio ir sutapimo. Aptarsiu kiekvieną kategoriją, tada surašysiu ir aprašysiu keletą kiekvienos kategorijos pavyzdžių.
Kiti dizaino modelių tipai
Jei galvojate, kad yra daugiau tipų modelių, esate teisus. Vėlesniame šios serijos straipsnyje bus aptariami papildomi dizaino modelių tipai: sąveikos, architektūriniai, organizaciniai ir komunikacijos / pristatymo modeliai.
Kūrybos modeliai
A kūrybos modelis apibendrina akimirksnio procesą, atskiriant objektų kūrimą, sudarymą ir vaizdavimą nuo jais besiremiančio kodo. Klasės kūrybos modeliai naudoti paveldėjimą keičiant klases, kurios yra momentinės, ir objekto kūrybos modeliai perduoti momentizavimą kitiems objektams.
- Abstraktus fabrikas: Šis modelis suteikia sąsają, kad būtų galima apjungti atskirų gamyklų grupę, turinčią bendrą temą, nenurodant konkrečių klasių.
- Statybininkas: Atskiria sudėtingo objekto konstrukciją nuo jo vaizdavimo, suteikdamas galimybę tam pačiam statybos procesui sukurti įvairias reprezentacijas. Abstraktūs objektų konstravimo žingsniai leidžia skirtingai įgyvendinti veiksmus, kad būtų galima sukurti skirtingus objektų vaizdus.
- Gamyklos metodas: Apibrėžia sąsają objektui kurti, tačiau leidžia poklasiams nuspręsti, kurią klasę instancijuoti. Šis modelis leidžia klasei atidėti egzempliorių į poklasius. Priklausomybės injekcijos yra susijusios. (Žr. Šaltinius.)
- Tingus inicijavimas: Šis modelis suteikia mums galimybę atidėti objektų kūrimą, duomenų bazės paiešką ar kitą brangų procesą, kol pirmą kartą reikės rezultato.
- Multiton: Išplečia „singleton“ koncepciją, kad būtų galima valdyti įvardytų klasės egzempliorių žemėlapį kaip raktų ir vertės poras, ir suteikia visuotinį prieigos prie jų tašką.
- Objektų telkinys: Laikykite pradinių objektų rinkinį paruoštą naudoti, o ne paskirstykite ir sunaikinkite pagal pareikalavimą. Siekiama išvengti brangių išteklių įsigijimo ir utilizavimo perdirbant objektus, kurie nebenaudojami.
- Prototipas: Nurodo objektų rūšis, kuriuos reikia sukurti naudojant prototipinį egzempliorių, tada sukurkite naujų objektų, nukopijuodami šį prototipą. Prototipinis egzempliorius klonuojamas, kad būtų sukurti nauji objektai.
- Išteklių įsigijimas yra inicijavimas: Šis modelis užtikrina, kad ištekliai bus automatiškai ir tinkamai inicijuoti ir susigrąžinti, susiejant juos su tinkamų objektų gyvenimo trukme. Ištekliai įgyjami inicijuojant objektą, kai nėra galimybės juos panaudoti, kol jie yra prieinami, ir išleidžiami sunaikinant tuos pačius objektus, kurie garantuotai vyks net ir klaidų atveju.
- Singletonas: Užtikrina, kad klasėje yra tik vienas egzempliorius, ir suteikia visuotinį prieigos prie šio egzemplioriaus tašką.
