Tölvumál - 01.07.2007, Blaðsíða 22

2 2 | T Ö LV U M Á L T Ö LV U M Á L | 2 3
Hvað eru hönnunarmunstur?
En hvað eru hönnunarmunstur? Ímyndum okkur að við séum að leysa
ákveðið vandamál eins og að hanna notendaviðmót. Hvernig förum við
að því að tengja saman framsetningu, vinnslu og gögn? Þetta er ekki nýtt
vandamál. Menn hafa verið að leysa svipuð verkefni áratugum saman. Þegar
betur er að gáð gengur hugbúnaðargerð að einhverju leiti út á að leysa sömu
verkefnin aftur og aftur. Til er þekkt lausn á ofangreindu vandamáli, munstur
sem nefnt er Model-View-Controller (Fowler, Model View Controller, 2002).
Þetta munstur var fyrst notað í hönnun SmallTalk á 8. áratugnum og gengur
út á að aðskilja vinnslu og viðmót. Síðan þá hefur þetta munstur komið fram
aftur og aftur við lausn sambærilegra verkefna.
Hönnunarmunstur eru þekktar lausnir fyrir endurtekin vandamál. Með því að
skilgreina og flokka munstur má búa til samansafn af lausnum sem hægt
er að leita í þegar verið er að hanna hugbúnað. Það var einmitt það sem
brautryðjendurnir á þessu sviði gerðu. Þeir Erich Gamma, Richard Helm,
Ralph Johnson og John Vlissides eða Gang of Four (GoF) eins og þeir eru
vanalega kallaðir, gáfu árið 1995 út bókina Design Patterns: Elements of
Reusable Object-Oriented Software sem er líklega sú áhrifamesta á þessu
sviði og skilgreinir munstur fyrir hlutbundin forritunarmál.
Notkun munstra
Tökum dæmi um verkefni þar sem einfalt munstur reynist mjög vel. Gefum
okkur að við séum með vefverslunarkerfi og ein einingin í því er sölueining.
Þessi eining hefur það hlutverk að ganga frá kaupum. Í því felst að nota
greiðslumiðlun (t.d. tengingu til banka eða kortafyrirtækis), minnka birgðir
o.s.frv. Nú eru aðrar einingar í kerfinu sem þurfa að vita um sölu. Það gætu
verið einingar sem sýna sölutölur eða lagerstöðu. Ein leið er auðvitað að nota
gagnagrunninn til þessa og að allar einingar sæki upplýsingar þangað. Það
getur þó sett óþarfa álag á grunninn. Hvað ef sölueiningin myndi bara láta
aðrar einingar vita? Þegar sala á sér stað kallar sölueiningin á aðar einingar.
Það hljómar kannski sniðugt og er mjög auðvelt að skilja, en væri í raun afleit
hönnun. Í hvert skipti sem ný eining þarf að vita um sölu, þarf að uppfæra
sölueininguna. Sölueiningin er svo orðin háð mörgum ólíkum eininguna sem
Hugbúnaðarkerfi geta verið með flóknustu verkum manna. Sem dæmi má nefna að talið er að
nýútgefið stýrikerfi frá Microsoft, Vista, sé yfir 50 milljón línur af kóða (Ganssle, 2005). Þó fæst
tölvukerfi séu af þeirri stærðargráðu, getur flækjustig verið fljótt að aukast í hugbúnaðargerð.
Sem betur fer hafa tölvunarfræðingar þróað ýmsar aðferðir til að auðvelda byggingu stórra
sem smárra kerfi. Meðal þeirra er notkun hönnunarmunstra og ramma en þær aðferðir eru
lykilatriði í hugbúnaðargerð í dag.
hafa ekkert með sölu að gera. Slík kerfi eru hræðileg í viðhaldi. Lausnin er í
raun mjög einföld. Hægt er að nota svokallað Observer munstur (WikiPedia,
2007). Þetta munstur lýsir eins konar áskriftarkerfi, þar sem notandi eða
áhorfandi gerist áskrifandi að ákveðum upplýsingum með því að hlusta.
Sölueiningin gæti þannig skilgreint hlustaraskil sem aðar einingar útfæra
og óska eftir að gerast áskrifendur að söluupplýsingum. Þannig myndi
sölueiningin láta allar þessar einingar vita án þess að vera háð þeim. Ef
bætist við ný eining sem einnig hefur áhuga á upplýsingum um sölu, þarf ekki
að uppfæra sölueininguna.
Kostir munstra
Kostir þess að þekkja og nota munstur eru margvíslegir. Munstur eru tilbúnar
og þekktar aðferðir við hugbúnaðargerð. Þau geta því minnkað hönnunartíma
þar sem verið er að nota þekktar leiðir í stað þess að finna hjólið upp aftur.
Einnig er það mikill kostur að vita til þess að þekktar lausnir hafa margsinnis
verið prófaðar og vitað er að þær virka sem og hvernig þær virka. Þá geta
munstur auðveldað mjög samskipti þróunarteyma.
Munstur auðvelda samskipti
Samskipti eru auðvitað mikilvæg í hugbúnaðargerð, sérstaklega þegar rætt
er um hönnun og tillögur um hvernig eigi að byggja hugbúnaðinn. Í störfum
mínum sem hugbúnaðararkítekt, hef ég setið ótal fundi þar sem menn koma
saman og ræða málin. Oft hefur mikill tími farið í að útskýra leiðir og jafnvel
hefur komið fyrir að menn eru að því virðist ósammála, en eru svo í raun að
tala um sömu hluti en nota ólíkar leiðir til að tjá sig. Með því að koma upp
sameiginlegu og þekktu málfari má minnka umræður og koma í veg fyrir
misskilning.
Það hefur tekið nokkur ár að finna sameiginlegan orðaforða um munstur. Sá
galli sem hefur fylgt hönnunarmunstrum er að menn eru að nota sömu hugtök
fyrir ólík munstur. Nærtækasta dæmið er munstrið Value Object (Fowler,
Value Object, 2002) en það munstur lýsir klasa sem hefur það hlutverk að
hafa ákveðna stöðu. Martin Fowler skrifar í bók sinni, Patterns of Enterprise
Application Architecture (Fowler, Patterns of Enterprise Application
HÖNNUNARMUNSTRA
OG RAMMA