Tag objectgeoriënteerd programmeren
De allegorie van de grot
Plato zegt: stel je een groep mensen voor, vastgebonden – in een grot dus. Hun hele leven lang zien ze alleen de schaduwen op de muren, van bewakers die verhalen vertellen voor een groot vuur. Die groep mensen zou denken dat de schaduwen op de muur de echte dingen zijn.
Wat zegt deze code?
De namen in onze code – van variabelen, velden, methoden, parameters – beschrijven wat de code doet. De naam van een class beschrijft haar wezen: integer, Url, ResourceHelper. Anders dan bij mensen gaat de existentie van code niet vooraf aan haar essentie. Code is bepaald, bepaald door haar functie. Wat die functie is, weet een goede programmeur in een naam te vangen.
Symmetrische en asymmetrische overerving
Code heeft niet alleen esthetische kwaliteiten. Het communiceert ook een intentie, een bedoeling. Code vertelt een verhaal. Zoals de manier waarop een personage wordt geïntroduceerd in een roman, ons iets vertelt over de rol en het karakter van dat personage, zo vertelt de manier waarop we bepaalde concepten in onze codebase vastleggen hoe we deze moeten “lezen”. – Code heeft, net als onze natuurlijke taal, een betekenis.
Overerving, compositie en dependency injection
Mijn collega had overerving toegepast om de nieuwe functionaliteit een plek te kunnen geven. De afgelopen maanden had ik gemerkt dat dit voor hem, en veel van mijn andere teamgenoten, een go to-oplossing vormt om code te kunnen hergebruiken. Maar ik was niet helemaal tevreden met het resultaat van die strategie. Ik voelde meer voor een oplossing die gebruik maakt van compositie. Het leek me een mooie gelegenheid om wat ideeën over deze concepten op papier te zetten.
Objectgeoriënteerd programmeren draait niet om objecten
Van Anjana Vakil leerde ik een interessante les: objectgeoriënteerd programmeren draait niet om objecten, het draait om het uitwisselen van informatie.
Eerlijke domeinmodellen
Options en Eithers vormen nog maar de eerste aanzetten voor het idee van eerlijke functies. Het zijn constructen die, op het oog althans, redelijk beperkt blijven tot het technische domein. Maar het idee van eerlijke functies past ook uitstekend bij de praktijk van het modelleren van een domein, zoals gebruikelijk in Domain-Driven Design. Dat is een les die ik leerde van Scott Wlaschin op DevTernity.
Objectgeoriënteerd en functioneel BTW berekenen - Revisited
Ik plaatste een tijd geleden wat kanttekeningen bij mijn aanpak Enrico Buonanno’s uitdaging om een objectgeoriënteerde BTW-calculator te schrijven. Zo zette ik mijn vraagtekens bij het feit dat ik zijn oorspronkelijke model één op één overnam. Die keuze bracht met ertoe een aparte VatCalculator-class te definiëren. En hoewel die objectgeoriënteerd was opgezet, viel deze makkelijk om te schrijven naar een functionele variant. De vraag wierp zich op: hoe objectgeoriënteerd is die oplossing? Is de vergelijking daarmee wel eerlijk? Hoe zou een “echt” objectgeoriënteerde oplossing eruit zien?
Objectgeoriënteerd en functioneel BTW berekenen
In het eerste hoofdstuk van Enrico Buonanno’s Functional Programming in C# (Second Edition) demonstreert de auteur wat functionele features van C# aan de hand van een concreet voorbeeld: het berekenen van de BTW op een (lijst) product(en). Buonanno raadt de lezer aan om dezelfde functionaliteit ook op een objectgeoriënteerde manier te implementeren, om die oplossing te kunnen contrasteren met de zijne. Dus dat is precies wat ik heb gedaan.
Heb je die setter echt nodig?
"prop" + tab + tab - welke C#-ontwikkelaar maakt niet bijna dagelijks dankbaar gebruik van dat code snippet om zijn ontwikkelsnelheid te verhogen? Standaard properties zijn zo alomtegenwoordig in de wereld van objectgeoriënteerd programmeren in het algemeen - en C# in het bijzonder - dat je er haast niet meer bij stilstaat dat het ook anders kan. Maar dat het ook anders kan, leerde ik dankzij Spencer Schneidenbach, in een uitstekende lezing over immutability (onveranderlijkheid).
Low code: een nieuw paradigma?
Een deel van de teams in het bedrijf waar ik voor werk is overgestapt op dat wat low code development wordt genoemd. In plaats van applicaties regel voor regel met de hand te schrijven, klikken ze deze in elkaar met behulp van een tool. Hoe verhoudt deze ontwikkelmethode zich tot “ouderwets” programmeren? Luidt low code een nieuw ontwikkelparadigma in?