Käyttöliittymäkomponenttien tunnistaminen jatkuu uudella iterointikierroksella. Listatuista komponenteista etsitään yhteisiä tekijöitä, jotka voidaan koota yleisemmäksi komponentiksi. Esimerkiksi edellisellä kierroksella löydetyt listauskomponentit laativat hyvin samannäköisiä listoja sivuille. Ainoastaan listojen sisältö muuttuu. Jokainen listauskomponentti voi käyttää listan rakentamiseen yleistä listakomponenttia. Oheisessa pseudokoodissa olen valottanut ajatusta yhteisestä listakomponentista.
class Sidebar {
public void searchBox();
public String newest() {
return generalList(newItems);
}
public String categories() {
return generalList(categoryItems);
}
public String months() {
return generalList(items(range = MONTH));
}
public String years() {
return generalList(items(range = YEAR));
}
public String tags() {
return generalList(tagItems);
}
}Esimerkissä yleinen listauskomponentti generalList() saa parametrina kokoelman listattavia objekteja tilanteen mukaan. Listauskomponentti ei ota kantaa listattavaan sisältöön. Sen tehtävänä on vain muuntaa kokoelma HTML-listaksi, jotta kokoelman sisältö voidaan näyttää sivulla. Komponentille on siis välitettävä valmiiksi laadittu kokoelma, joka voidaan sellaisenaan listata. Olen määritellyt pseudokoodissa käyttöliittymäkomponenttien paluuarvon tyypiksi merkkijonon (String), sillä valmiiksi sivulle tulostettava HTML-koodi on tyypillisesti juuri merkkijonomuotoa.
Tyylioppaan päivitys
Sitä mukaa kuin käyttöliittymäkomponentteja on tunnistettu ja ne on päätetty toteuttaa, lisätään tyylioppaaseen (Design Guide) otsikko jokaiselle komponentille. Otsikon alle kirjoitetaan lyhyt kuvaus komponentista, mitä sillä tehdään, missä sitä suositellaan käytettäväksi ja ennen kaikkea miten komponenttia käytetään ohjelmakoodista käsin. Yleisille komponenteille kirjoitetaan aivan oma lukunsa tyylioppaaseen. Sivukohtaiset komponentit luetellaan kunkin sivun yhteydessä omassa kappaleessaan. Esimerkissäni mainittujen listauskomponenttien lisäksi käyttöliittymästä löytyy toki paljon muitakin komponentteja. Tällaisia ovat yleinen lomakekomponentti, blogeissa joskus nähtävä kalenterikomponentti ja arkistohakuja varten oma hakukomponentti. Lomakekomponentti voi käyttää jälleen yleisiä lomakkeen kenttiä rakentavia komponentteja jne. Komponenttien tunnistaminen kannattaa lopettaa jossakin vaiheessa. Hyvä raja voisi olla komponentteja kahdessa tai kolmessa tasossa. Tämä tarkoittaa sitä, että käyttöliittymäelementti pitää pysytä rakentamaan kahdella tai enintään kolmella komponentilla, jotka kutsuvat toisiaan siis enintään kahden tai kolmen komponentin kautta.
Komponenttipaletin etuja
Lopullisia käyttöliittymän sivuja on nyt helppo koota rakentamalla ne tunnistetuista komponenteista. Sivujen rakennetta voidaan myös helposti muuttaa sijoittamalla komponentit uudelleen. Ohjelmistoprojektin aikataulutus ja resursointi helpottuu, kun eri komponenttien ohjelmointi jaetaan usean tekijän kesken. Hyvin suunniteltuja komponentteja voidaan valmistaa rinnakkain, jolloin ne valmistuvat nopeasti. Sovelluksen laajentaminen sen valmistumisen jälkeen helpottuu, koska uudet sivut rakennetaan jo valmistuneista käyttöliittymäkomponenteista. Mikäli uudet toiminnot vaativat uusia komponentteja, on niidenkin ohjelmointi helpompaa, kun ohjeistusta saadaan tyylioppaasta. Komponenttikirjaston käyttö lisää ohjelmiston laadukkuutta, kun virheiden mahdollisuus vähenee verrattuna siihen, että samankaltainen ohjelmakoodi olisi kirjoitettu eri sivujen toiminnallisuuden yhteydessä uudelleen ja uudelleen. Komponentit siis vähentävät redundanttia ohjelmakoodia ja helpottavat myöhempää järjestelmän ylläpitoa. Koodista tulee ylläpidettävämpää, kun koodin määrä vähenee ja ohjelmiston rakenne yksinkertaistuu loogisemmaksi ja ymmärrettävämmäksi.