Object Thinking

Het duurt vaak een tijdje om echt object georienteerd te ontwikkelen. Het komt in mijn ogen door de associaties die we met software ontwikkeling hebben, we gebruiken de verkeerde metaforen.

We hebben het vaak over bouw en architectuur en dan leg je de associatie met de bouw wereld. In de bouw werk je met blauwdrukken en UML diagrammen hebben wat weg hiervan. Alleen zijn de objecten die je in de bouw gebruikt heel erg statisch, ze hebben alleen attributen, geen gedrag. Een steen kan wel gewicht dragen, een raam kan open gaan, maar toch zul je bij een gebouw niet denken aan een compositie van objecten met gedrag. Je kunt ook denken aan een machine. Heeft wel wat meer gedrag en zo, maar de individuele tandwieltjes en moertjes niet zo.

Een fabriek komt misschien beter in de buurt. Je hebt de verschillende componenten die met elkaar interactie hebben, er is dus gedrag. Je kunt de data zien als de grondstof die verwerkt wordt door de fabriek. Maar ook hier hebben de grondstoffen geen gedrag. De machines hebben dat en dan krijg je het structureel denken. Procedures die bewerkingen uitvoeren op data.

Oorspronkelijk zat de informatica in de hoek van de wiskunde. In de wiskunde ben je heel veel bezig met functies en algortimes. Dit kun je makkelijk vertalen naar code. Maar in de wiskunde leer je niet echt in objecten denken en het ligt toch meer tegen het functioneel programmeren of sql aan.

Ik heb weleens geprobeerd software te zien als een leger met soldaten. Het is opgedeeld in verschillende onderdelen met verschillende eigenschappen en verantwoordingen. Het delegeren van verantwoordelijkheden is heel natuurlijk, een generaal gaat niet micro managen. Je hebt een duidelijke base class, iedereen is soldaat en je denkt heel natuurlijk in termen van gedrag.
Je ontwikkelt je software net zoals je een leger ontwikkeld: je definieert gedrag in je objecten. Je bereid ze voor op actie. In plaats van architecten heb je nu strategen.

Ondanks mijn morele bezwaren tegen dit metafoor vind ik dat heb beter past bij object georienteerd denken dan de bouw of proces metafoor. De volgende keer dat ik een object definieer, zal ik denken aan een soldaat die orders uitvoert.

On 2008-05-27

Terugkijken op TDD/BDD

Ben weer in een coachende rol terecht gekomen en het leek me zinvol om terug te kijken op hoe ik op mijn manier van werken ben gekomen. Ik begin met mijn belangrijkste stokpaardje: Test Driven Development.

In 2001 ben ik begonnen met het schrijven van unit testen voor mijn code. Bij het coderen bedacht ik van tevoren eerst wel de klassen/modules en methodes, maar ging bij het implementeren ervan eerst de testen voor schrijven. Het test first was dus op methode nivo. Het belangrijkste effect was dat ik precies wist wanneer ik klaar was. Voorheen was er toch altijd het knagend gevoel dat je iets vergeten was, of dat je te lang door ging met de code terwijl het al af was.

Een ander gunstig side effect kwam door de beperking van de testframeworks: het moeilijk kunnen testen van de GUI en de database. De gui omdat het vrij lastig is om deze aan te sturen, de database omdat ik met de steeds wijzigende inhoud van de database zat. Om toch zoveel mogelijk code te kunnen testen scheidde ik automatisch mijn gui en database code van mijn midden laag.

De volgende stap was het leren werken met mock's. In eerste instantie gebruikte ik de mockframeworks als stub voor de database in testen, maar gaandeweg leerde ik dat het bij mock testing om het valideren van gedrag gaat. Het kan best lang duren voordat je dit goed snapt, omdat je best wel veel tijd kwijt kan zijn aan het maken van je mock testen. De testen vergen veel boilerplate code in java, je kunt alleen mocken van een interface, en het resultaat vind ik erg slecht leesbaar.

De stap van mock testing naar Behaviour Driven Development is erg klein. Het rspec framework maakt effectief gebruik van de engelse taal om in de juiste termen te denken. Het ingebouwde mock framework vergt dankzij ruby minder boilerplate code en de examples zijn beter leesbaar hierdoor. Toch maakte ik bij rspec eerst nog de fout om vooral de state van de objecten na een actie te controleren en niet zozeer naar het gedrag van de objecten te kijken.

Ik gebruik nu rspec meer als design tool om tot een ontwerp te komen en inzichten te verkrijgen. Ik ben dan meer bezig met de verantwoordelijkheden van objecten en interactie tussen objecten. Eigenlijk dus een beetje volgens de CRC card methode. Het heeft wel jaren geduurd voordat ik deze context switch heb kunnen maken en waarschijnlijk is het inzicht pas gekomen nadat ik smalltalk had geleerd.

Hoewel het totale leertraject jaren geduurd heeft en ik nog steeds bezig ben, was de eerste stap vrij snel gemaakt en kan ik mij daar geen grote leercurve herinneren. Ook geen discipline problemen, de directe feedback van de groene balk gaf me een 'rush' en dat was verslavend. Ik denk dat, dat ook de essentie is van het succesvol omarmen van TDD. Als je er niet dat fijne gevoel van krijgt kost het alleen maar energie. Dat is namelijk de enige verklaring die ik kan bedenken voor het feit dat zoveel programmeurs er nog moeite mee hebben. Ik zal daar rekening mee houden als ik het overbreng en focussen op de snelle feedback.

On 2008-05-15

On 2008-05-14

  • still having connection problems #

On 2008-05-13

On 2008-05-10

On 2008-05-09

  • migrating the mainframe #
  • deploying some java stuff on a solaris machine, maybe use capistrano #
  • preparing a capistrano recipe #

On 2008-05-08

  • building an ssh tunnel #
  • teaching unix to a windows user #

On 2008-05-04

  • don't care about the weather, coding is more fun #