Programmēšana

Ievads dizaina modeļos, 1. daļa: Dizaina modeļu vēsture un klasifikācija

Ir izstrādātas daudzas stratēģijas, lai vienkāršotu un samazinātu programmatūras projektēšanas izmaksas, īpaši uzturēšanas jomā. Mācīties identificēt un strādāt ar atkārtoti lietojamām programmatūras sastāvdaļām (dažkārt dēvētas par programmatūras integrētās shēmas) ir viena stratēģija. Dizaina modeļu izmantošana ir vēl viena.

Šis raksts uzsāk trīs daļu sēriju par dizaina modeļiem. Šajā daļā es iepazīstināšu ar dizaina modeļu konceptuālo ietvaru un iepazīšos ar dizaina modeļa novērtēšanas paraugu konkrētam lietošanas gadījumam. Es arī apspriedīšu dizaina modeļu vēsturi un anti-modeļus. Visbeidzot, es klasificēšu un apkopošu visbiežāk izmantotos programmatūras projektēšanas modeļus, kas ir atklāti un dokumentēti pēdējos pāris gadu desmitos.

Kas ir dizaina modelis?

Izstrādāt atkārtoti lietojamu objektorientētu programmatūru, kas modelē esošu sistēmu, ir patiesi sarežģīti. Programmatūras izstrādātājam sistēmas entītijas jāiedala klasēs, kuru publiskās saskarnes nav pārāk sarežģītas, jāizveido attiecības starp klasēm, jāatklāj mantojuma hierarhijas un daudz kas cits. Tā kā lielākā daļa programmatūras joprojām tiek izmantota ilgi pēc tās uzrakstīšanas, programmatūras izstrādātājiem ir jāpievēršas pašreizējām lietojumprogrammu prasībām, vienlaikus saglabājot savu kodu un infrastruktūru pietiekami elastīgu, lai apmierinātu nākotnes vajadzības.

Pieredzējuši objektorientēti izstrādātāji ir atklājuši, ka programmatūras projektēšanas modeļi atvieglo stabilu un izturīgu programmatūras sistēmu kodēšanu. Ir efektīvi atkārtoti izmantot šos dizaina modeļus, nevis pastāvīgi izstrādāt jaunus risinājumus no nulles, un tas samazina daļu no kļūdu riska. Katrs noformējuma modelis identificē atkārtotu dizaina problēmu konkrētā lietojuma kontekstā, pēc tam piedāvā vispārinātu, atkārtoti lietojamu risinājumu, kas ir piemērots dažādiem lietojuma scenārijiem.

"A dizaina raksts apraksta klases un mijiedarbojošos objektus, kas izmantoti, lai atrisinātu vispārēju dizaina problēmu konkrētā kontekstā. "

Daži izstrādātāji definē a dizaina raksts kā klases kodēta entītija (piemēram, saistīts saraksts vai bitu vektors), turpretī citi saka, ka noformējuma paraugs ir visā lietojumprogrammā vai apakšsistēmā. Es uzskatu, ka a dizaina raksts apraksta klases un mijiedarbojošos objektus, ko izmanto, lai atrisinātu vispārēju dizaina problēmu konkrētā kontekstā. Formālāk dizaina raksts tiek norādīts kā apraksts, kas sastāv no četriem pamatelementiem:

  1. A nosaukums kas apraksta dizaina modeli un dod mums vārdu krājumu tā apspriešanai
  2. A problēmu kas identificē dizaina problēmu, kas jāatrisina, kā arī kontekstu, kurā problēma rodas
  3. A risinājums problēmai, kurai (programmatūras dizaina modeļa kontekstā) jāidentificē klases un objekti, kas veicina dizainu, kā arī to attiecības un citi faktori
  4. Paskaidrojums sekas dizaina modeļa izmantošanu

Lai identificētu izmantojamo dizaina modeli, vispirms skaidri jāidentificē problēma, kuru mēģināt atrisināt; tieši tur problēmu dizaina raksta apraksta elements ir noderīgs. Viena dizaina modeļa izvēle, salīdzinot ar citu, parasti ietver arī kompromisus, kas var ietekmēt lietojumprogrammas vai sistēmas elastību un turpmāko uzturēšanu. Tāpēc ir svarīgi saprast sekas izmantot noteiktu dizaina modeli, pirms sākat to ieviest.

Dizaina modeļa novērtēšana

Apsveriet uzdevumu izveidot sarežģītu lietotāja saskarni, izmantojot pogas, tekstu laukus un citus komponentus, kas nav konteineri. Kompozīta dizaina konteineri tiek uzskatīti par sastāvdaļām, kas ļauj konteinerus un to komponentus (konteinerus un ne-konteinerus) ligzdot citos konteineros un darīt to rekursīvi. Ja mēs izvēlētos neizmantot kombinēto modeli, mums būtu jāizveido daudzi specializēti komponenti, kas nav konteineri (piemēram, viens komponents, kurā apvienots, piemēram, paroles teksta lauks un pieteikšanās poga), ko ir grūtāk sasniegt.

To pārdomājuši, mēs saprotam problēmu, kuru mēģinām atrisināt, un Composite modeļa piedāvāto risinājumu. Bet kādas ir šī modeļa izmantošanas sekas?

Composite izmantošana nozīmē, ka jūsu klases hierarhijās tiks sajaukti konteinera un bez konteinera komponenti. Vienkāršāki klienti pret konteineru un bez konteinera komponentiem izturēsies vienādi. UI būs vieglāk ieviest jauna veida komponentus. Kompozīts var arī novest pie pārāk vispārināts dizainu, padarot grūtāk ierobežot to sastāvdaļu veidus, kuras var pievienot konteineram. Tā kā jūs nevarēsiet paļauties uz kompilatoru, lai ieviestu tipa ierobežojumus, jums būs jāizmanto izpildlaika tipa pārbaudes.

Kas vainas izpildlaika tipa pārbaudēm?

Runtime tipa pārbaudes ietver ja paziņojumus un instanceof operatoru, kas noved pie trausla koda. Ja aizmirstat atjaunināt izpildlaika tipa pārbaudi, attīstoties lietojumprogrammas prasībām, pēc tam varat ieviest kļūdas.

Ir arī iespējams izvēlēties atbilstošu dizaina modeli un to izmantot nepareizi. The Divreiz pārbaudīta bloķēšana modelis ir klasisks piemērs. Divreiz pārbaudīta bloķēšana samazina bloķēšanas iegūšanas pieskaitāmās izmaksas, vispirms pārbaudot bloķēšanas kritēriju, faktiski neiegūstot slēdzeni, un pēc tam iegūstot slēdzeni tikai tad, ja pārbaude norāda, ka bloķēšana ir nepieciešama. Lai gan tas izskatījās labi uz papīra, dubultā pārbaudītā bloķēšanā JDK 1.4 bija dažas slēptas sarežģītības. Kad JDK 5 paplašināja semantiku gaistošs atslēgvārds, izstrādātāji beidzot varēja izmantot dubultā pārbaudītā bloķēšanas modeļa priekšrocības.

Vairāk par divreiz pārbaudītu bloķēšanu

Sk. "Divreiz pārbaudīta bloķēšana: gudra, bet salauzta" un "Vai divreiz pārbaudītu bloķēšanu var salabot?" (Brian Goetz, JavaWorld), lai uzzinātu vairāk par to, kāpēc šis modelis nedarbojās JDK 1.4 un agrāk. Lai uzzinātu vairāk par DCL precizēšanu JDK 5 un jaunākās versijās, skatiet "Deklarācija" Double-Checked Locking is Broken "" (Merilendas Universitātes Datorzinātņu katedra, Deivids Bekons u.c.).

Anti-modeļi

Ja parasti tiek izmantots dizaina modelis, bet tas ir neefektīvs un / vai neproduktīvs, dizaina raksts ir pazīstams kā anti-modelis. Varētu apgalvot, ka dubultpārbaudīta bloķēšana, kas izmantota JDK 1.4 un agrāk, bija antimode. Es teiktu, ka tā šajā kontekstā bija tikai slikta ideja. Lai slikta ideja izvērstos par anti-modeli, ir jāievēro šādi nosacījumi (skat. Resursus).

  • Atkārtots darbības, procesa vai struktūras modelis, kas sākotnēji šķiet izdevīgs, bet galu galā rada vairāk sliktu seku nekā izdevīgu rezultātu.
  • Pastāv alternatīvs risinājums, kas ir skaidri dokumentēts, praksē pierādīts un atkārtojams.

Lai gan dubultā pārbaudītā bloķēšana JDK 1.4 izpildīja pirmo prasību par anti-modelis, tā neatbilda otrajai: lai gan jūs varētu izmantot sinhronizēts lai atrisinātu slinka inicializācijas problēmu daudzšķautņainā vidē, tas būtu pārvarējis iemeslu, kāpēc vispirms izmantojat Double-pārbaudītu bloķēšanu.

Strupceļa anti-modeļi

Anti-modeļu atpazīšana ir priekšnoteikums, lai no tiem izvairītos. Izlasiet Obi Ezechukwu trīsdaļīgo sēriju, lai iepazītos ar trim anti-modeļiem, kas ir slaveni ar strupceļa izraisīšanu:

  • Nav šķīrējtiesas
  • Darbinieku apkopošana
  • Papildu bloķēšana

Dizaina modeļu vēsture

Dizaina modeļi radās 1970. gadu beigās, kad tika publicēts Rakstu valoda: pilsētas, ēkas, celtniecība autors ir arhitekts Kristofers Aleksandrs un daži citi. Šī grāmata iepazīstināja ar dizaina modeļiem arhitektūras kontekstā, parādot 253 modeļus, kas kopīgi veidoja to, ko autori sauca par modeļa valoda.

Dizaina modeļu ironija

Lai gan programmatūras projektēšanai izmantotie dizaina modeļi izseko to sākumam Rakstu valoda, šo arhitektūras darbu ietekmēja toreiz jaunā valoda, lai aprakstītu datorprogrammēšanu un dizainu.

Modeļa valodas jēdziens vēlāk parādījās Donalda Normana un Stefana Drapera grāmatās Lietotāju centrēta sistēmas projektēšana, kas tika publicēts 1986. gadā. Šī grāmata ieteica rakstu valodas pielietot mijiedarbības dizains, kas ir interaktīvu digitālo produktu, vides, sistēmu un pakalpojumu projektēšanas prakse cilvēkiem.

Tikmēr Kents Beks un Vards Kaningems bija sākuši pētīt modeļus un to pielietojamību programmatūras projektēšanā. 1987. gadā viņi izmantoja virkni dizaina modeļu, lai palīdzētu Tektronix pusvadītāju testēšanas sistēmu grupai, kurai bija grūtības pabeigt dizaina projektu. Beks un Kaningems sekoja Aleksandra ieteikumiem par lietotāju centrētu dizainu (ļaujot projekta lietotāju pārstāvjiem noteikt dizaina iznākumu), vienlaikus nodrošinot arī dažus dizaina modeļus, lai atvieglotu darbu.

Strādājot pie doktora disertācijas, Ērihs Gamma saprata arī atkārtotu dizaina modeļu nozīmi. Viņš uzskatīja, ka dizaina modeļi var atvieglot atkārtoti lietojamas, uz objektu orientētas programmatūras rakstīšanu, un pārdomāja, kā tos efektīvi dokumentēt un komunicēt. Pirms 1991. gada Eiropas konferences par objektorientētu programmēšanu Gamma un Ričards Helms sāka veidot modeļus.

OOPSLA seminārā, kas notika 1991. gadā, Gammai un Helmam pievienojās Ralfs Džonsons un Džons Vlisīds. Šis Četru banda (GoF), kā viņi vēlāk bija zināmi, turpināja rakstīt populāro Dizaina modeļi: atkārtoti lietojamas objektorientētas programmatūras elementi, kas dokumentē 23 dizaina modeļus trīs kategorijās.

Dizaina modeļu mūsdienu evolūcija

Kopš sākotnējās GoF grāmatas dizaina modeļi turpina attīstīties, it īpaši tāpēc, ka programmatūras izstrādātāji ir saskārušies ar jaunām problēmām, kas saistītas ar aparatūras un lietojumprogrammu prasību maiņu.

1994. gadā tika atklāta ASV bāzēta bezpeļņas organizācija, kas pazīstama kā Hillside Group Programmu rakstu valodas, ikgadēju konferenču grupa, kuras mērķis ir attīstīt un pilnveidot programmatūras projektēšanas modeļu mākslu. Šīs notiekošās konferences ir devušas daudz domēnu specifisko dizaina modeļu piemēru. Piemēram, dizaina modeļi vienlaicīguma kontekstā.

Kristofers Aleksandrs OOPSLA

OOPSLA 96 galveno uzrunu teica arhitekts Kristofers Aleksandrs. Aleksandrs pārdomāja savu darbu un to, kā objektorientētā programmēšanas kopiena ir sasniegusi un nokavējusi atzīmi, pieņemot un pielāgojot programmatūras idejas par rakstu valodām. Aleksandra uzrunu var izlasīt pilnībā: "Rakstu teorijas pirmsākumi: teorijas nākotne un dzīvās pasaules radīšana".

1998. gadā Marks Grand atbrīvots Raksti Java valodā. Šajā grāmatā bija iekļauti dizaina modeļi, kas nav atrasti GoF grāmatā, ieskaitot vienlaicīguma modeļus. Grand izmantoja arī vienoto modelēšanas valodu (UML), lai aprakstītu dizaina modeļus un to risinājumus. Grāmatas piemēri tika izteikti un aprakstīti Java valodā.

Programmatūras dizaina modeļi pēc klasifikācijas

Mūsdienu programmatūras dizaina modeļi tiek plaši iedalīti četrās kategorijās, pamatojoties uz to izmantošanu: radošais, strukturālais, uzvedības un vienlaicīgums. Es apspriedīšu katru kategoriju un pēc tam uzskaitīšu un aprakstīšu dažus no tiem izcilākos modeļus.

Cita veida dizaina modeļi

Ja domājat, ka ir vairāk veidu modeļu, jums ir taisnība. Vēlākā šīs sērijas rakstā tiks apspriesti papildu dizaina modeļu veidi: saskarsmes, arhitektūras, organizatoriskie un komunikācijas / prezentācijas modeļi.

Radošie modeļi

A radošais modelis abstrahē instantizācijas procesu, nošķirot objektu izveidi, sastāvu un attēlojumu no koda, kas uz tiem paļaujas. Klases radošie modeļi izmantojiet mantojumu, lai mainītu klases, kas tiek instantificētas, un objekta radīšanas modeļi deleģēt instantiation citiem objektiem.

  • Abstrakta fabrika: Šis modelis nodrošina saskarni, lai iekapsulētu atsevišķu rūpnīcu grupu, kurām ir kopīga tēma, nenorādot to konkrētās klases.
  • Celtnieks: Atdala sarežģīta objekta konstrukciju no tā attēlojuma, ļaujot vienam un tam pašam būvniecības procesam izveidot dažādus attēlojumus. Objekta konstrukcijas pakāpju abstrakcija ļauj dažādām soļu realizācijām konstruēt dažādus objektu attēlojumus.
  • Rūpnīcas metode: Definē saskarni objekta izveidei, bet ļauj apakšklasēm izlemt, kuru klasi instancēt. Šis modelis ļauj klasei atlikt apakšklasi. Atkarības injekcija ir saistīta. (Skatīt resursus.)
  • Slinka inicializācija: Šis modelis dod mums iespēju aizkavēt objektu izveidi, datu bāzes meklēšanu vai citu dārgu procesu, līdz rezultāts ir nepieciešams pirmo reizi.
  • Multitons: Tiek izvērsts vienskaitļa jēdziens, lai pārvaldītu nosaukto klases gadījumu karti kā atslēgas vērtību pārus un nodrošina tiem globālu piekļuves punktu.
  • Objekta baseins: Saglabājiet inicializētu objektu kopu gatavu lietošanai, nevis pēc pieprasījuma piešķirt un iznīcināt. Mērķis ir izvairīties no dārgas resursu iegādes un meliorācijas, pārstrādājot objektus, kas vairs netiek izmantoti.
  • Prototips: Norāda objektu veidus, kas jāizveido, izmantojot prototipisku gadījumu, pēc tam izveidojiet jaunus objektus, kopējot šo prototipu. Prototipiskais gadījums tiek klonēts, lai ģenerētu jaunus objektus.
  • Resursu iegūšana ir inicializācija: Šis modelis nodrošina, ka resursi tiek automātiski un pareizi inicializēti un atgūti, piesaistot tos piemērotu objektu dzīves ilgumam. Resursi tiek iegūti objekta inicializācijas laikā, kad nav iespēju tos izmantot, pirms tie ir pieejami, un tiek atbrīvoti līdz ar to pašu objektu iznīcināšanu, kas tiek garantēts, ka tas notiks arī kļūdu gadījumā.
  • Singletons: Nodrošina, ka klasei ir tikai viens gadījums, un nodrošina globālu piekļuves punktu šim gadījumam.
$config[zx-auto] not found$config[zx-overlay] not found