Disainimuster
Tarkvaraarenduses on disainimuster selgelt määratletud abstraktne lahendus mingile levinud probleemile tarkvaradisaini kontekstis.[1][2] Iga disainimuster on mõeldud kasutamiseks mingi kindla tarkvara disainiga seotud probleemi kontekstis. Disainimustreid võib kirjeldada kui üldistatud kuju sarnastest lahendusest kindlale probleemile.[3]
Disainimustriga kaasneb kirjeldus kõikidest mustris sisalduvatest tarkvarakomponentidest, nende rollidest, vastutusaladest ja omavahelisest koostööst. Samuti on disainimustriga kirjeldatud, kus ja millal on sobilik seda kasutada, kuidas see suhestub muude tarkvara disaini kaalutlustega ning selle mustri kasutamisega kaasnevad hüved ja pahed.[4]
Komponendid muuda
Gamma jt (1994)[5] esitavad disainimustri kui koosluse neljast komponendist:
- Nimi. Hästi valitud nimi aitab luua esmase arusaama disainimustri eesmärgist ja töömehhanismist. Samuti annab nimi pidepunkti, et mustrile viidata, hõlbustades suhtlust kolleegidega ja tarkvarakomponentide tekstilist kirjeldamist.[5][6]
- Probleemikirjeldus üldises vormis, mis loob arusaama, mis probleemi võimaldab disainimuster lahendada või ennetada. Kirjeldusest peaks tekkima ettekujutus, millal ja miks disainimustrit kasutada.[5]
- Lahendus. Eelnevalt kirjeldatud probleemi lahendus peab kirjeldama disainimustri kõigi tarkvarakomponentide struktuuri, suhteid, vastutusi ja koostöövooge. Siinkohal on oluline, et lahenduse kirjeldus poleks liiga spetsiifiline (nt fikseeritud teostusega), vaid abstraktsel tasemel, sest disainimuster peaks olema rakendatav mitmetes erinevates olukordades.[5]
- Tagajärjed. Tagajärjed peaks selgitama, mis positiivsed ja/või negatiivsed tagajärjed võivad tekkida, kui süsteemi disainimuster sisse tuua. Tagajärgede hulka võib kuuluda näiteks mingi operatsiooni ajalise keerukuse suurenemine, aga samas süsteemi paindlikkuse suurenemine.[5] Disainimuster, mis on parim lahendus probleemile ühes tarkvarasüsteemis, ei pruugi olla parim lahendus samale probleemile teises tarkvarasüsteemis.[6]
Hüved muuda
Disainimustrid hõlbustavad kasulike lahenduste taaskasutamist, aidates valida võimalike lahenduste hulgast sellise, mis aitab enim suurendada süsteemi taaskasutatavust. Samuti võib disainimustrite kasutamine suurendada koodi mõistetavust ja sellega panustada tarkvara hooldatavusesse, kuna disainimustriga kaasnev nimetus tarkvarakomponendile (nt klassi nimi objektorienteeritud kontekstis) kommunikeerib selle vastutusvaldkonda ja töömehhanismi disainimustriga tuttavale lugejale.[7]
Pahed muuda
Disainimustrite üleliigne kasutamine võib mõjuda lähtekoodi kvaliteedile negatiivselt. Disainimustrite vales olukorras või valesti kasutamine võib suurendada lähtekoodi keerukust, vähendades loetavust ja süsteemi hallatavust.[8]
Vajadus disainimustri järele võib tekkida ka asjaolust, et programmeerimiskeeles on puudu teatud funktsionid, mille puudumise kompenseerimiseks on välja kujunenud disainimuster. Seda tõendab see, et mõnes keeles esinevad disainimustrid pole teistes keeltes vajalikud, kuna on seal väljendatavad mõne võtmesõna või sisseehitatud funktsionidega.[9]
Viited muuda
- ↑ "Enimkasutatavad disainimustrid". TTÜ Java õppematerjalid (eesti keeles). Tallinna Tehnikaülikool. 17. november 2019. Vaadatud 12.01.2022.
Disainimustrid on mõeldud korduvate probleemide efektiivseks lahendamiseks.
{{netiviide}}: CS1 hooldus: tundmatu keel (link) - ↑ Gunnar Peipman. "Disainimustrid". Gunnar Peipmani õppematerjalid (eesti keeles). Vaadatud 12.01.2022.
Disainimustrid (design patterns) on kogum väljapakutud ühtseid lahendusi sagedasti korduvatele programmeerimisalastele probleemidele.
{{netiviide}}: CS1 hooldus: tundmatu keel (link) - ↑ Martin Fowler (2002). Patterns of Enterprise Application Architecture (Inglise keel). USA: Addison-Wesley. Lk 10.
{{raamatuviide}}: CS1 hooldus: tundmatu keel (link) - ↑ Gamma E., Helm R., Johnson R., Vlissides J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software (Inglise keel). USA: Addison-Wesley. Lk 13.
The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities. Each design pattern focuses on a particular object-oriented design problem or issue. It describes when it applies, whether it can be applied in view of other design constraints, and the consequences and trade-offs of its use.
{{raamatuviide}}: CS1 hooldus: mitu nime: autorite loend (link) CS1 hooldus: tundmatu keel (link) - ↑ 5,0 5,1 5,2 5,3 5,4 Gamma E., Helm R., Johnson R., Vlissides J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software (Inglise keel). USA: Addison-Wesley. Lk 12-13.
{{raamatuviide}}: CS1 hooldus: mitu nime: autorite loend (link) CS1 hooldus: tundmatu keel (link) - ↑ 6,0 6,1 Martin Fowler (1. august 2006). "Writing Software Patterns". Martin Fowleri blogi (inglise keeles). Vaadatud 12.01.2022.
{{netiviide}}: CS1 hooldus: tundmatu keel (link) - ↑ Gamma E., Helm R., Johnson R., Vlissides J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software (Inglise keel). USA: Addison-Wesley. Lk 12.
Design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design patterns makes them more accessible to developers of new systems. Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise reusability. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent. Put simply, design patterns help a designer get a design "right" faster.
{{raamatuviide}}: CS1 hooldus: mitu nime: autorite loend (link) CS1 hooldus: tundmatu keel (link) - ↑ "Enimkasutatavad disainimustrid". TTÜ Java õppematerjalid (eesti keeles). 17. november 2019. Originaali arhiivikoopia seisuga 12.01.2022. Vaadatud 12.01.2022.
Samas pole disainimustreid võimalik või mõistlik alati kasutada. Teatud olukordades võib see muuta koodi loetavust halvemaks, näiteks kui üritatakse kasutada mustrit vales olukorras, kus see pole kasutamiseks ette nähtud.
{{netiviide}}: CS1 hooldus: tundmatu keel (link) - ↑ Hannemann, J., Kiczales, G. (november 2002). "Design pattern implementation in Java and AspectJ". Special Interest Group on Programming Languages (inglise keeles). Vaadatud 12.01.2022.
{{netiviide}}: CS1 hooldus: mitu nime: autorite loend (link) CS1 hooldus: tundmatu keel (link)