Etikettarkiv: modellering

Begreppsförvirring

För någon vecka sedan försökte jag under ett samtal förklara varför jag gillar det här med systemutveckling. Under mitt något långdragna och flummiga resonemang minns jag att jag sa att man nog måste ha något av en pedantisk ådra, ett slags driv som gör att man finner nöje i att skapa ordning i kaoset. En av anledningarna till att mitt resonemang blev ganska krångligt var nog att ordet ”pedantisk” inte kändes riktigt rätt, att det inte uttryckte det jag egentligen ville ha sagt. För jag är allt annat än pedant som person; hemma accepterar jag det ständiga kaos som råder när tre vilda barn yr runt som virvelvindar. Det får vara lite damm i hörnen, det är okej. Nej, pedant var inte rätt ord, det är alldeles för negativt laddat.

För någon dag sedan ögnade jag igenom ett blogginlägg med den spännande titeln ”The most important skill in software development”. Det borde jag ha gjort tidigare, för när jag hade skummat färdigt inlägget insåg jag att det hade fångat det begrepp jag borde ha använt mig av under min konversation (i alla fall om jag hade varit engelskspråkig). I blogginlägget finns att läsa att ”organization skills” är det viktigaste för en programmerare, vilket man med lite god vilja kan översätta till ”färdigheter att organisera och strukturera”. Istället för att prata om pedantiska drag borde jag istället ha sagt att jag gillar att organisera och strukturera kod. Min förmåga att göra det lämnar jag osagd, men att säga så hade i vilket fall bättre gett uttryck för varför jag gillar systemutveckling.

Jag gillar att organisera och strukturera kod – kanske nu mer än någonsin när familjesituationen gör att ordning är svårt att hålla på hemmaplan – och jag gör det genom att refaktorera och modellera. Ramverk och teknikaliteter löser sig alltid.

En önskning till PHP-tomten

Som ni kanske redan har läst här på min fina blogg har jag dykt ner lite i PHP under föräldraledigheten. Säga vad man vill om PHP men med Laravel kan man ha riktigt kul och få en vettig projektstruktur på köpet. Två flugor i en smäll så att säga. Nåväl, nu efter ett par månaders hackande tänkte jag ta tillfället i akt att ändå gnälla lite eftersom det är det vi människor är bäst på. 😉

Det finns mycket som man skulle kunna gnälla över när ämnet är PHP, särskilt ur mitt perspektiv som (främst) Javaprogrammerare. Men alla språk har sina begränsningar, sin historia och sin ryggsäck, och om verktyget – det vill säga språket – inte passar ändamålet är det väl bättre att byta verktyg än att sura ihop? Med det sagt finns det ändå en stor grej som jag saknar vad det gäller objektorienteringen i PHP, och det är det här med package-private visibility. Ni vet, den där varianten där man i Java utelämnar visibility i till exempel en metoddeklaration. I Java innebär det att metoden endast kan anropas från klasser i samma paket. Det kan låta som lite ”jaha” men det är faktiskt någonting väldigt användbart när man modellerar. Genom att använda denna visibility på ett förnuftigt sätt kan klasser inom ett och samma paket samarbeta utan att man behöver exponera sånt som bara är relevant inom paketet ut mot resten av systemet. Ett paket kan då designas att endast ha ett fåtal metoder som går att anropa utifrån. Det gör att vi kraftigt kan begränsa interaktionspunkterna med koden i paketet vilket i sin tur ger oss bättre förutsättningar att ha en förvaltningsbar kodbas.

Ett enkelt exempel på när avsaknaden av package-private visibility ställer till modelleringsbekymmer är när man vill bygga sig en Factory som skapar objekt av Foo, vi kallar den för FooFactory. Eftersom vi vill att FooFactory alltid ska sköta konstruktionen av objekt av typen Foo kan vi då i Java sätta package-private visibility på konstruktorn i Foo. Eftersom vi har package-private visibility på konstruktorn har vi effektivt sett till att det inte går att skapa upp instanser av Foo från någon annanstans än inom dess paket. Vi kan sedan välja att publicera en metod ut publikt mot resten av systemet i FooFactory som konstruerar objekt av typen Foo efter konstens alla regler.

I PHP är det en annan historia. Eftersom det inte finns någon package-private visibility får vi snällt låta konstruktorn vara publik. Visst kan vi skapa upp en Factory – exempel på det finns här – men då får vi helt enkelt gilla läget och låta konstruktorn i Foo vara publik. Vi har då alltså exponerat två sätt att skapa upp instanser av Foo – dels genom Foos konstruktor och via FooFactory – men vi vill bara att den senare av dem ska användas. Hur ska man kunna försäkra sig om det? Tja, jag antar att man får ha disciplin och berätta för nytillkomna programmerare att de ska hålla sig borta från Foos konstruktor. Men modelleringsmässigt känns det riktigt trist. Om man nu har bemödat sig med att lägga till stöd för namespaces i PHP kunde de väl ändå peta in package-private visibility också.

Sådär, då var dagens I-landsproblem avhandlat. Tack för mig. 🙂

Konceptuella modeller

En arbetsskada jag fick med mig från min tid som doktorand är förtjusningen över enkla och tydliga konceptuella modeller. Jag vill minnas att min far en gång sa att det går att bli intresserad av nästan vad som helst, bara man lägger ner tillräckligt med energi på det. Efter sju år på universitetet är det svårt att säga om det där med konceptuella modeller någonsin var ett genuint intresse hos mig eller om jag formade mig själv till att tycka om dem. Men det finns någonting vackert i att ta något komplext, abstrahera det och fånga essensen i en modell. Dessutom kan jag efter min tid i den akademiska världen konstatera att det är jävligt svårt.

Anledningen till att jag pratar om det här är att jag sprang på en sådan modell tidigare idag när jag bläddrade igenom Evans fantastiska bok Domain-Driven Design – Tackling Complexity in the Heart of Software. Modellen i sig är inte på något sätt central i boken men den är sjukt tydlig och enkel vilket gör att den kvalar in på min ”modeller jag gillar”-lista. Dessutom var den så enkel att rita av att jag slipper åka dit för stöld. 😛 Här har vi den:

model

Jag ska beskriva begreppen så att det hela blir lite mer begripligt för er som inte har koll på Domain Driven Design (DDD). Modellen (”Model” i figuren ovan) är ett centralt begrepp i DDD och utgör en abstraktion över utvalda delar av en domän som kan användas för att lösa verksamhetsproblem. Modellen i sig är något abstrakt – var och en av oss bär på olika mentala modeller över hur saker och ting förhåller sig till varandra – och den kan konkretiseras på lite olika sätt. Ett sätt är att rita ett diagram. Ett annat sätt (som förespråkas i DDD) är att implementera modellen i programkod. Implementationens utformning blir då systemets design (”Design” i figuren ovan). Det man med DDD vill uppnå är att minimera avståndet mellan Model och Design till den grad att det inte finns någon egentlig skillnad. Måhända utopiskt men mycket fräckt.

Allt eftersom man får en ökad förståelse av modellen gäller det att överföra det man lärt sig till designen. Detta är alltså en iterativ process (som pilarna påvisar). Centralt i figuren har vi även ”Paradigm” som en länk mellan Model och Design. Här menar Evans att valet av programmeringsparadigm är en viktig faktor för att man ska kunna uttrycka modellen på bästa sätt. Det kan vara så att objektorientering inte är det bästa valet bara för att det är något man är van vid.

Anyhow, jag tror jag har fått fram min poäng. Enkla och tydliga figurer får mig att mysa! 🙂

Min professionella inriktning

Tidigare idag när jag plockade in disk i diskmaskinen tänkte jag lite nostalgiskt tillbaka på sena kvällar med PHP-programmering och metalmusik. Då handlade det om att göra bandets hemsida slagkraftig och classy. Vi skulle ju ta över världen och då var vi såklart tvungna att ha en tuff hemsida och vi hade knappast råd att anlita någon att göra den åt oss.

Idag – femton år senare – är systemutveckling inte längre en hobby utan mitt levebröd, men fortfarande något som jag är mycket intresserad av och lägger en stor klick av min fritid på. Allt eftersom tiden gått har jag fått ganska bra kläm på vad som intresserar mig i rollen som utvecklare – en roll som kan ses lite som ”jack of all trades” – och här landar jag väldigt långt ifrån tekniskt trolleri såsom ramverk (e.g. Hibernate). Bara ordet ”ramverk” gör mig sömning och jag blir på nåt sätt automatiskt lite motvilligt inställd. Varför? Jo, därför att ramverk nästan alltid inkräktar på det viktigaste som systemet har: domänmodellen. Lämpligt nog för denna text är det just här mitt intresse brinner som starkast.

En fin gammal dator.
En fin gammal dator.

Utmaningen i att implementera en modell (eller flera för den delen) som innefattar relevanta verksamhetsbegrepp (och deras inbördes beroenden) som kan användas för att lösa verkliga verksamhetsproblem får mig att bli riktigt pepp. Om man dessutom siktar på att kunna kommunicera modellen vertikalt i verksamheten – det vill säga att begrepp som används i kod även ska vara begripliga för t ex kravställare – flyttas fokus från tekniska ramverk till begreppsinnebörd och till att anpassa den implementerade modellen vartefter verksamheten ändrar kurs.

Som den insatte kanske har förstått är jag en DDD fanboy, det sticker jag inte under stolen med. Evans bok är fortfarande något av det bästa jag har läst i facklitteratur och den fick mig att sätta ord på vem jag är som systemutvecklare. Jag är inte algoritmgurun, optimeringsnissen eller DBA. Jag är en skäggig modelleringsnörd med god analytisk förmåga på jakt efter den perfekta modellen. Vilket är jävligt svårt i dessa ramverkstider.