Hoe flexibeler een applicatie is ontwikkeld hoe breder deze kan worden ingezet en zal aansluiten bij de behoefte van een organisatie. Deze flexibiliteit ontstaat doordat bepaalde aspecten van de applicatie zoals het datamodel, de code, de gelaagdheid generiek zijn opgezet. Er bestaan veel misverstanden over genericiteit en het wordt nogal eens verkeerd toegepast, ook zien sommige opdrachtgevers generiek als het toverwoord waardoor de applicatie alles aan kan.
Het woord generiek als woord werd in de vorige eeuw voornamelijk toegepast bij medicijnen waarvan het patent was verlopen. Het bekendste voorbeeld is aspirine. Asperin was oorspronkelijk de naam van het medicijn maar nu staat het voor pijnstiller. Pijnstiller is een generiek woord of verzamelnaam voor alle medicijnen die wij kennen om pijn te bestrijden.
Maandag is generiek voor alle maandagen. Maandag 1 April is generiek voor alle maandagen die op 1 April vallen en is dus minder generiek. Maandag 1 April 1985 is niet meer generiek. Het gaat om precies 1 dag.
Om een vertaling te maken naar techniek: Stel een applicatie die op een school gebruikt worden heeft een tabel Studenten waarin de gegevens van studenten opgeslagen worden. Als de applicatie ook iets doet met docenten zal er dus ook een tabel docenten gemaakt moeten worden. Welke velden zullen deze tabellen bevatten? Waarschijnlijk zaken zoals naam, geboortedatum, BSN, etc. Deze velden komen dus meteen twee keer voor en hebben dus ook twee venster nodig om beheerd te worden en zo verder. Zowel studenten als leraren zijn mensen met veel dezelfde eigenschappen, het is dus logisch om beide in 1 tabel onder te brengen en hetgeen wat hun student of docent maakt te scheiden. De tabel mensen is dus generiek voor studenten en docenten, maar wat schiet je hier nu mee op? Waarin zit het voordeel voor generiek? Voornamelijk wellicht dat de programmeur maar 1 basis venster hoeft te maken voor het vullen van basis gegevens. Het datamodel wordt namelijk iets ingewikkelder. Als een leek naar het datamodel kijkt ziet hij direct het verschil tussen docenten en studenten. Dit voorbeeld dient alleen ter illustratie dat generiek maken niet per se betekend dat iets beter wordt door het generiek te maken. Per voorbeeld moet je ook kijken voor wie het voordeel is.
Een extreem voorbeeld van generiek is dat je elke database kunt nabouwen met maar twee tabellen (en eigenlijk zou het ook in één tabel kunnen). Eén tabel voor het benoemen van tabellen en kolommen, één tabel om records uniek te identificeren en kolomwaardes in op te slaan.
In dit laatste voorbeeld kun je alles namaken zonder aan de tabelstructuur te hoeven wijzigen. Maar wat schiet je hiermee op? Performance zal per definitie minder zijn, en de complexiteit komt te liggen bij de inrichter van de database en het schrijven van de documentatie. Ik schrijf dit omdat genericiteit altijd een doel moet dienen en dat je heel gemakkelijk je doel voorbij kan schieten. Ook zorgt het generiek maken van een database en applicatie dat de complexiteit verschuift van de programmeur naar de inrichter. Ook kan genericiteit een extra complexiteit met zich meebrengen. De impact van een wijziging wordt als een regel groter en het testen daardoor belangrijker.
Het is vaak helemaal niet nodig heel generiek te zijn. Je moet de genericiteit vooral toepassen op de gebieden die aan verandering onderhevig zijn.
Van bedrijfsprocessen weet je dat deze niet in steen gebeiteld zijn en natuurlijk gezien veranderen. Een bedrijfsproces zou dus generiek moeten worden opgezet. Een voordeel is dat het bedrijfsproces ook veel dichter staat bij de business analist dan bij de programmeur. De programmeur maakt zich verdienstelijk door de inrichting generiek te houden zodat de business analist het proces kan vormgeven en inrichten. De impact van een wijziging is daardoor organisatorisch en niet iets waar een database administrator (DBA) van wakker ligt.
Niet generiek is als je een object of tabel veldnamen heeft als: KlachtId, Indiener, Oplosser, KlachtGemeldOp. Wel generiek is als je een object of tabel veldnamen heeft als: ProcesId, ProcesStarter, ProcesEigenaar, ProcesInvoerDatum. De eerste genoemde velden passen alleen bij een klachtproces, de laatstgenoemde velden passen bij ieder bedrijfsproces. Dat een proces van het type klacht wel velden nodig heeft specifiek voor (bepaalde) klachten is triviaal.
Generiek maken van software gebeurt of verschillende lagen. Het datamodel kan generiek zijn door een tabel personen te gebruiken in plaats van Studenten en Docenten. De applicatie zelf kan uit meerdere lagen bestaan: Presentatielaag, Businesslaag, Datalaag. Door een datalaag te gebruiken kun je de applicatie bijvoorbeeld op verschillende typen databases laten draaien zoals Microsoft SQL Server, Oracle, MySQL, etc. In diverse blogs zal ik meer op deze specifieke zaken ingaan. Om toch een stokpaardje van me aan te halen vind ik dat een datalaag meestal geschreven moet worden voor één type database. Het grote nadeel van generiek in de datalaag is anders dat je bepaalde voordelen van een database niet kunt gebruiken omdat andere databases deze niet bevatten. Met andere woorden; doordat de applicatie op meerdere typen databases kan functioneren kun je alleen de functionaliteit gebruiken die op alle databases aanwezig is. Dit is overigens heel kort door de bocht, maar is wel een belangrijk inzicht.
De mate van genericiteit heeft invloed op de levenscyclus van een applicatie. Applicaties veranderen. Als de uiteindelijk functionaliteit erg afwijkt van het beginvisie waaruit de applicatie ontwikkeld is, dan is de rek er op een gegeven moment uit en moet de applicatie vanaf de grond weer opnieuw geschreven worden.
In deze blog heb ik een introductie gegeven over genericiteit zonder de diepte in te gaan of bepaalde voorbeelden uit te werken, deze komen aan bod in volgende blogs. Heb je een verzoek hierin of vragen? Ik vind het leuk als je contact met me opneemt en ligt één en ander graag toe.