Puslespill (Puzzle). Foto: Flickr/create_joy (CC)

Utenfra fungerer en modul som en sort boks; man gir beskjeder inn og man får svar tilbake. Man vet ikke hvordan den sorte boksen kommer frem til svaret. Det gjør det enklere å forholde seg til støttefunksjoner, så man kan fokusere på den funksjonaliteten man skal lage. Jeg kaller det støttefunksjoner fordi disse funksjonene ikke er viktige; eller rettere sagt så er funksjonaliteten man arbeider med for øyeblikket mye viktigere enn en hvilken som helst annen annen modul.

Vedlikeholdbarhet

Behovet for modulbasert arkitektur oppstår når systemer blir for store til at én eller to personer kan ha oversikt over hele systemet. Da blir det viktig med vedlikeholdbare moduler av håndterbare mengder med kode.

Vedlikeholdbarhet betyr ikke at koden til stadighet må endres, noe som faktisk fungerer mot sin hensikt. Dersom modulen endres for ofte med for store endringer kan det innføre feil. Mye ny funksjonalitet kan gjøre modulen uoversiktlig og mindre vedlikeholdbar. En vedlikeholdbar modul bidrar til at resten av systemet får en tydelig måte å kommunisere med modulen på, og dersom man støter på feil så skal man klare å fikse feilen.

Eksempel på modulbasert løsning

Et svært enkelt og overordnet eksempel på en modulbasert nettbutikkløsning

Kjernen av MyWebShop kommuniserer mot eksterne komponenter over definerte grensesnitt. Det er ikke sikkert at alle komponenter har grensesnitt basert på åpne standarder, som SQL, SMTP og HTTP. Det kan være behov for å definere nye grensesnitt i bedriften. For eksempel kan kommunikasjon mot et CMS-system skje via et nytt grensesnitt vi kaller ProductService som tilbyr funksjoner som er nyttige for vår nettbutikk. På denne måten definerer vi tydelig hvilke funksjoner nettbutikken har behov for, samtidig som vi skjuler andre funksjoner som CMS-systemet tilbyr som ikke er viktige for vårt system.

Når kommunikasjon mellom moduler foregår over definerte grensesnitt, så kan moduler byttes ut med ny moduler ved behov. For eksempel kan modulen My Simple CMS byttes ut med et mer avansert og bedre CMS-system dersom nettbutikken vår blir større og får nye behov som den gamle modulen ikke kan tilby. Om den nye modulen ikke støtter det samme grensesnittet som den gamle kan man lage et veldig lite oversettingslag, kalt for et adapter, som oversetter mellom vårt eget ProductService-grensesnitt og den nye modulen.

Samhandling

Et ofte brukt tilfelle av modulbasert programvare er når data skal behandles i flere ledd. Samme grensesnitt kan brukes i front av flere forskjellige moduler. For eksempel kan et spamfilter kobles på foran e-posttjeneren slik at e-post kan filtreres før det lagres i brukerens innboks, og uønsket e-post kastes uten at brukeren ser e-posten. Fordelen med modulbasert arkitektur er klar, man får et mer oversiktlig system med komponenter som kan settes sammen og byttes ut ved behov.

Problemet oppstår først når man etter en stund skal inn og gjøre endringer i allerede eksisterende funksjonalitet, helst uten å brekke hele systemet. Kanskje man kaller på funksjoner som man egentlig ikke aner hvor finnes i kodetreet, man har ikke peiling på hvor denne globale variabelen “er_satt” ble satt, enda mindre pailing hvor den kanskje ble endret på veien, og den smarte workarounden som du la inn for et halvt år siden er nå blitt et midtpunkt i systemet ditt. Hva gjør du så? Jo, du legger til en ny “if”…

… eller du starter på nytt. Tanken på å starte fra scratch kan virke skremmende på de fleste, men du har et gigantisk fortrinn foran hvem som helst andre som skulle laget det samme. Du vet hva du skal lage. Du har laget det før, og du skal lage det samme på nytt, men denne gangen med modularitet i fokus.

Det finnes noen små og enkle leveregler når det gjelder programmering. Ingen linjer skal være lenger enn 80 tegn i bredden og ingen funksjoner skal være på flere linjer enn hva skjermbildet ditt kan vise, og gjerne litt mindre. En skummel situasjon er hvor man får løkker inni løkker inni løkker, fordi dette skaper en uorden og det er vanskelig å se på koden og umiddelbart se hva som blir gjort med dataene. Kanskje kan en av løkkene flyttes ut som en ny funksjon, som bare håndterer et sett av dataene. Kanskje denne funksjonen kan benyttes et annet sted i programmet ditt. Tankegangen bak modularitet er å få oversiktlig og gjenbrukbar kode.

Vær gnien på hvilke data du sender mellom funksjonene. Man kan si at dersom antall parametere inn til en funksjon overstiger tre, så gjør enten funksjonen alt for mye eller så hører disse dataene sammen og du kan kanskje lage en klasse som representerer dataene dine istedet. Husk at dataene du sender til en funksjon skal ha høy integritet, eller med andre ord “høre sammen”. Dersom du har behov for å sende data som ikke hører sammen eller som ikke er på samme nivå i systemet ditt, som for eksempel en liste med fotballag sammen med en referanse til databasekontrolleren din, da bør du vurdere å tenke nytt. Kanskje mottakerfunksjonen kan klare å finne referansen til databasekontrolleren selv, eller kanskje du kan sende lista med fotballag til en klasse som arver fra databasekontrolleren som har direkte tilgang til databasen via denne.

For å ta et konkret eksempel på et prosjekt jeg har jobbet med for litt siden, stod vi foran et valg hvor vi kunne lage noen funksjoner for å håndtere forskjellige filtyper og bruke if-else-kontrollstrukturer for å kalle på riktige funksjoner, eller å lage nye klasser for hver filtype og bruke en hashmap for å finne ut hvilken som skulle brukes. Vi gikk for valg nummer to. Vi lagde en felles klasse med en abstrakt metode, som alle de forkjellige filtypene arvet fra. Dermed kunne vi lage noen små og oversiktlige klasser, hvor navnet på klassene indikerte hvilken filtype de håndterte, og disse klassene arvet fra fellesklassen med forskjellige implementasjoner av den abstrakte metoden for å håndtere filtypens unike handling. Det som viste seg var at mange av disse filtypene skulle håndteres likt. Det som kunne blitt et hav av if-elsif ble nå bare en utvidelse av hashmapen for å peke alle filtypene med samme handlingsmønster til samme klasse.

Dette er bare et lite eksempel av hvordan man kan programmere modulært. Det er flere måter å programmere modulært på. Man kan for eksempel lage en plugin-arkitektur hvor man kan stikke inn små moduler som gjør en bestemt oppgave totalt uavhengig av de andre modulene man skulle bruke. Det man må passe på er at disse innstikksmodulene ikke blir for store og monolitiske, men at man også fører modularitetstankegangen videre ut i modulene sine og helt ut i hver funksjon.

Kort oppsummert handler dette om “best practices”. Innen objektorient programmering heter det at enhver klasse skal ha høy kohesjon og svak kobling. Dette gjelder også for strukturell programmering. En funksjon skal ikke kunne alt, men skal være en ekspert på sitt område.