View

Maandag, 23 december 2002
Hoe communiceren een GUI- en een business-objectenlaag met elkaar?

View

Een populaire mogelijkheid is om een view te definiëren, met daarin op maat gesneden informatie. Dat houdt de GUI-laag mooi onafhankelijk van de objectenlaag, zo luidt de redenatie.

Tja, leuk bedacht, maar...

  1. Het is wat ouderwets, lijkt op de dataflows van decennia geleden tussen batch jobs.
  2. De objectenlaag heeft in zo'n geval een brengplicht.
    Als de informatiescope van de GUI-laag verandert dan moet de GUI-laag zelf, de viewdefinitie en ook de businessobjectenlaag aangepast worden. Dat is een drievoudige update. De zo gewenste onafhankelijkheid is ver te zoeken.
  3. Het gevaar bestaat dat de programmeur van de objectenlaag zich gedwongen ziet om
    • het zekere voor het onzekere te nemen en de view overcompleet te maken,
    • vol te stoppen met allerlei informatie die niet gebruikt wordt,
    • de negatieve effecten voor de performance voor lief te nemen.

Methodes

Het kan een stuk simpeler: gewone methodes, rechtstreeks van GUI naar objectenlaag. De objectenlaag kan gericht op zoek gaan naar informatie, maar alleen als erom gevraagd wordt.
  1. Het maakt mooi gebruik van moderne Object Oriëntatie. Achter een simpele method aanroep kan een wereld van functionaliteit zitten, maar dat blijft voor de GUI-laag mooi verborgen.
  2. De GUI-laag heeft een vraagplicht. En dat is niet zo gek, want alleen de GUI weet wat de GUI nodig heeft.
  3. Voor de objectenlaag maakt het niet uit van welk scherm een vraag komt. Er is een grote kans dat een method al bestaat, hergebruikt kan worden, zonder dat de objectenlaag of aangeroepen methoden hoeven te wijzigen.
Ja, ja, en de onafhankelijkheid der lagen dan? Wat gebeurt er als de classeboom verandert? Of de message definitie? Geen paniek. Door encapsulation zullen de meeste veranderingen ongemerkt aan de GUI-laag voorbij gaan. Zolang het contract tussen GUI-laag en OO laag hetzelfde blijft, mag de implementatie achter de schermen veranderen.

Alleen voor een stevige wijziging, met impact op de classeboom of de message definities, moet de GUI-laag mee veranderen. De directe koppeling tussen GUI-laag en objecten maakt snel duidelijk welke schermen mee moeten veranderen. Sommige schermen werken eenvoudig niet meer. Dat is geen probleem, maar werk:

  1. Maak nieuwe classes met nieuwe attribuut definitie,
  2. Definieer methodes op de juiste plaats,
  3. Pas de GUI-laag aan.
    De lijst van niet meer werkende schermen is een duidelijke "to-do" werklijst voor de programmeurs. Even de juiste method naar de juiste classe roepen en klaar, meestal een update van slechts enkele minuten.
Tot de volgende week,
Henk Jan Nootenboom

Met dank aan Theo Maas en Antoinette Coetzee voor hun inspirerende woorden en discussiebereidheid.