Afgod

Maandag, 14 mei 2001
  1. Is het gebruik van OO-concepten niet te complex voor een gemiddelde programmeur?
    Antwoord
  2. Leidt het gebruik van OO-concepten in programmeertalen bij software gebruikers niet tot zeer lastig te onderhouden software?
    Antwoord
  3. Bevinden we ons nu wel of niet in een Echnatonse fase?
    Antwoord
Deze vragen stonden afgelopen weekend in een column op blz 43 van Computable (computable.nl/...archief...). Bij deze m'n antwoorden.

OO niet te complex?

Nee, OO is wel te complex voor de gemiddelde programmeur.

De gemiddelde programmeur is al blij dat het lukt om de syntax van een taal door te krijgen, een while loopje en if statement te schrijven, SQL efficiënt te gebruiken. Bij functionaliteit van gemiddelde complexiteit is er voor de gemiddelde programmeur niets aan de hand.

Logisch data modelleren, tot derde normaal vorm, is al te complex voor de gemiddelde programmeur. En voor OO is logisch data modelleren slechts een eerste stap. Een ware OO expert beheerst de kunst van programmeren, data modelleren èn heeft daarnaast nog het mentale vermogen om

Nee, dit zal een gemiddelde programmeur nooit lukken. Dat hoeft ook niet. Er zijn genoeg conventionele talen voor de gemiddelde programmeur.

Leidt OO tot lastig onderhoud?

Nee, wat een onzin. Bij een goede OO aanpak heeft elke methode één en slechts één logische plaats.
  • Gedeelde functionaliteit kent één gedeelde oplossing en dus gedeelde ontwikkelkosten.
  • Gedeelde functionele veranderingen kennen gedeeld onderhoud, met gedeelde onderhoudskosten.
Bij onderhoud is snel en eenvoudig de eenduidige plek te vinden waar onderhoud nodig is. Ja, voor zware functionele wijzigingen is soms een ware aardbeving in de klasseboom nodig. Maar zelfs zo'n zware ingreep is meestal in één of twee dagen te doen. OO verlaagt de software onderhoudskosten.

Als er iets is dat wel tot hoge onderhoudskosten leidt dan is het wel conventioneel 'eiland denken', elke functie apart bouwen, tot het overzicht over het eilandenrijk compleet zoek is. Elke functionele wijziging begint dan hopelijk met een speurtocht in de code, maar waarschijnlijk met een lange speurtocht naar de code, met budget- en tijdoverschrijding als gevolg.

Is OO in een Echnatonse fase?

Nee, ook onzin.

OO is nooit de ene afgod geweest die een oplossing bood voor alle automatiseringsproblemen. Adviseurs die OO als panacee aanbevelen voor al uw automatiseringsproblemen verstaan hun vak niet.

OO is inmiddels al decennia oud, regeert al langer dan Farao Echnaton (att.net/...) ooit gedaan heeft. OO regeert echter niet heel automatiseringsland. OO heeft een specifiek toepassingsgebied, in de top van het marktsegment, projecten die zich kenmerken door:

  • complexe logica,
  • veel uitzonderingen,
  • een zwaar grafische user interface
Kortom, projecten die alleen goed aan te pakken zijn met goed gebruik van polymorpfisme, intheritance en encapsulation.

Advies

Gebruik OO waar nodig Gebruik conventionele tools voor de rest
Huur een OO vakman in voor een complex project. Wat 1 OO-er kan doen in een dag, lukt 10 gemiddelde programmeurs nog niet in 10 dagen. Gebruik een conventionele case tool voor eenvoudige applicaties, met slechts list-new-change-delete functionaliteit.
Voorbeelden van typische OO projecten: Voorbeelden:
  • data-entry systemen
  • order entry systemen, zoals simpele e-commerce
  • een eenvoudig CRM systeem.
Ja, ja, zuinige Hollanders, goede OO-ers zijn schaars en vragen hogere tarieven dan de gemiddelde programmeur. U hoort mij dan ook niet klagen. Op de toch al zo schaarse markt kunt u genoegen nemen met gemiddelde programmeurs, tegen een gemiddeld tarief.
Aanbevolen werkwijze: Vraag meerdere offertes aan, al dan niet met OO. Kijk niet alleen naar het uurtarief, ook naar het totaal bedrag. Wees niet verbaasd over grote verschillen in offertes. Elke IT-er heeft recht op z'n eigen afgod, maar dat hoeft niet op uw kosten.

Tot de volgende week,
Henk Jan Nootenboom