Frameworks - Deel 1, Theorie

Erik Stok (aka Baldo)

Enige tijd geleden ontstond er op het NLDelphi forum een discussie over frameworks. Het is er toen zelfs van gekomen dat een aantal enthousiastelingen bij elkaar kwam om eens te kijken naar een framework in de praktijk. Niet iedereen was natuurlijk in de gelegenheid om daar bij te zijn, dus vandaar deze reeks artikelen over frameworks.

Wat is een framework

Er komt een moment in de tijd dat je applicaties aan het programmeren bent dat je denkt: "Dit kan beter, efficiënter, mooier en op een standaard wijze worden geprogrammeerd." Toen voor mij en mijn collega dat moment aanbrak hebben we gezocht naar een richtlijn voor het op een standaard manier implementeren van applicaties. Al gauw struikelden we over de term "framework".

Maar wat is eigenlijk een framework? Helaas is er geen eenduidige definitie voor te vinden, zoals met zoveel zaken in de automatisering. De definitie waar mijn collega en ik ons het meest gelukkig mee voelen is de volgende:

"A framework is a skeleton of non-visual classes and a set of rules, upon which an application is build."

In het Nederlands staat er dus: "Een framework is een skelet van non-visuele classes en een set van regels, waarop een applicatie gebouwd wordt." Maar wat betekent dat eigenlijk?

Een skelet van non-visuele classes wil eigenlijk zeggen dat er een aantal classes een eenheid vormen (het skelet) waar iets mee gedaan kan worden. Het non-visuele zit hem in het feit dat het niet de bedoeling is dat deze classes ook maar iets van de uiteindelijk te bouwen user interface mogen bevatten. Die user interface hoort namelijk thuis in het laatste gedeelte van de definitie: de applicatie die op het framework gebouwd wordt.

Dan is er nog de set regels. Een set regels (of afspraken) is noodzakelijk om de werking van het skelet goed te laten verlopen. Het is namelijk onmogelijk (en niet wenselijk) om een programmeur die met een framework aan de slag gaat in een keurslijf te duwen waarmee de werking van het skelet van classes altijd goed gaat. Regels zijn een noodzaak om de interactie tussen de applicatie en het framework voorspelbaar en onderhoudbaar te maken, zonder dat daarvoor in code iets wordt afgedwongen.

Wat is een framework niet?

Omdat sommige mensen het begrip framework in het verleden uit zijn verband hebben geprobeerd te trekken, noem ik hier ook expliciet wat een framework dus niet is.

Een framework is geen set wizards. Dat er wizards worden gemaakt om programmeurs sneller op weg te helpen met een applicatie die op een framework wordt gebouwd is zonder meer handig, maar de wizards zelf maken geen onderdeel uit van het framework.

Een framework is ook geen set componenten. Het kan natuurlijk zo zijn dat het skelet van non-visuele classes bestaat uit allemaal componenten. Maar een componentenbibliotheek is niet per definitie een framework. Sommigen zeggen dan direct: "Maar de Delphi VCL is toch een framework?" Dat klopt wel, maar alleen omdat de Delphi VCL een skelet vormt en een set regels heeft waarmee gewerkt wordt om er applicaties mee te bouwen. Als er geen interactie tussen de verschillende onderdelen van de Delphi VCL was geweest, en er waren geen regels waarbinnen de componenten gebruikt kunnen worden, dan is de Delphi VCL geen framework te noemen.

Een framework is ook geen applicatiegenerator. Een tool die met een aantal stappen een hele applicatie in elkaar zet is geen framework. Een dynamisch te configureren set classes die afhankelijk van de configuratie een andere applicatie laat zien, is geen framework.

De voordelen van een framework

Met een dergelijke mooie definitie in de broekzak ben je nog steeds nergens als het werken met een framework geen voordelen biedt. Wat zijn de voordelen van het werken met een framework?

Het werken met een framework leidt tot een standaard manier van applicatieontwikkeling. Als er meerdere applicaties op een framework worden gebouwd, zullen die vanwege de interactie met het framework vele overeenkomsten vertonen.

Ook de onderhoudbaarheid van de applicaties verbetert, omdat zaken op een standaard manier zijn opgelost. Het framework helpt vanwege het skelet en de afspraken met het implementeren van zaken op standaard plaatsen in de code. Tevens worden bepaalde standaard zaken nu in het framework geïmplementeerd. Indien in die zaken een fout zit, dan heeft het oplossen ervan natuurlijk effect op alle applicaties die op het framework gebouwd zijn.

Hergebruik van code neemt ook toe door het bouwen van applicaties op een framework. Door in het framework standaardcode op te nemen zal door applicaties die op het framework gebouwd zijn deze code automatisch hergebruikt worden. Algemene problemen kunnen in het framework worden opgelost, waardoor niet het wiel op een aantal plaatsen hoeft te worden uitgevonden en geïmplementeerd.

Het laatste maar zeker niet het minste voordeel van het werken met een framework is dat het leidt tot betere software ontwikkeling in groepen. Door de regels is het beter te voorspellen waar een ander groepslid een bepaalde oplossing geïmplementeerd zal hebben. Tevens wordt de communicatie tussen verschillende onderdelen van de applicatie via het framework geregeld, wat er voor zorgt dat programmeurs impliciete afspraken hebben over hoe met elkaars onderdelen van de applicatie om te gaan.

De kwaliteiten van een goed framework

Allereerst dient een framework eenvoudig te zijn. Een framework met een hoge complexiteit leidt tot geen van de eerder genoemde voordelen. Iedere programmeur moet met het framework overweg kunnen en zaken moeten niet ingewikkelder worden geïmplementeerd dan noodzakelijk.

Een framework moet ook helder zijn. Er moet intuïtief kunnen worden aangevoeld waar welke code moet worden geïmplementeerd. Zaken als naamgeving en een duidelijke structuur van het skelet van non-visuele classes dragen daar aan bij.

Een framework moet ook duidelijke grenzen hebben. Een programmeur moet weten wat het framework nog voor hem doet en wat hij zelf zal moeten bouwen. Ook moet het toepassingsgebied van een framework duidelijk zijn: is het een framework voor webapplicaties, client-server applicaties, multi-tier applicaties of iets anders? Een onbegrensd framework is per definitie onduidelijk in toepasbaarheid, omdat teveel zaken op een algemene manier moeten worden opgelost wat weer zorgt voor minimale helderheid.

Uitbreidbaarheid is ook een belangrijke factor bij een goed framework. Als een framework tekort schiet in standaard functionaliteit, dan moet het voor een programmeur niet ingewikkeld zijn om voor een applicatie het framework uit te breiden met voor die applicatie specifieke classes, die mee kunnen functioneren in de globale werking van het framework. Het is anders slecht mogelijk om implementaties te doen van zaken die niet op basis van het framework kunnen worden opgelost.

Ook moet een framework voldoende mogelijkheden bieden om in te haken op zijn werking. Indien een programmeur niet in de gelegenheid wordt gesteld om op het gedrag van het framework te reageren, dan zal hij proberen om het framework te omzeilen. En dat laatste is niet wenselijk, want de hele reden dat er een framework wordt gewerkt is juist om er gebruik van te maken.

Een applicatie ombouwen naar een framework applicatie

Uitgaande van een bestaande applicatie, wat is dan de beste manier om van deze applicatie een framework applicatie te maken? Het eerste en meest belangrijke is dan natuurlijk het maken van het framework. Alles wat niet in het framework thuishoort is dan automatisch onderdeel van de applicatie die er op gebouwd is.

Richtlijnen om te bepalen welke zaken in het framework terecht dien te komen zijn de volgende:

De flow van een applicatie hoort thuis in een framework. Hiermee bedoel ik de interactie tussen de verschillende applicatie onderdelen. Hoe kom ik van het ene scherm in het andere? Hoe krijg ik bepaalde functionaliteit opgestart? Hoe geeft ik vanuit het de ene functionaliteit geselecteerde informatie door aan het andere? Dat soort zaken.

Management hoort thuis in een framework. Als een functionaliteit wordt opgestart moeten er zaken worden aangemaakt. Als een functionaliteit wordt afgesloten moeten deze zaken weer worden opgeruimd. Dit soort life-cycle management hoort thuis in een framework. Maar denk ook aan het vastleggen en over de applicatie distribueren van gebruikersrechten, globale instellingen enzovoorts.

Grofweg kun je stellen dat zaken die je in verschillende applicaties op dezelfde manier zou willen doen in aanmerking komen om onderdeel uit te maken van je framework.

Een eigen framework bouwen

Natuurlijk zal deze theorie in de praktijk gebracht moeten kunnen worden. Om de keuzes bij het maken van een framework en de voordelen van het werken met een framework duidelijk te maken zal ik daarom een klein framework gaan ontwikkelen: het NLDelphi framework. In de komende artikelen zal ik aan de hand van praktijkvoorbeelden proberen uit te leggen hoe de in dit artikel genoemde theorie op een Delphi framework van toepassing is.