Ontwerpers bedenken objecten, dingen die doen wat ze moeten doen. Met gedrag en eigenschappen die moeten passen in de situatie waarvoor ze bestemd zijn. Anders is het ontwerp niet goed.

Maar een object doet ook nog iets anders. Het behoort tot een groep, een klasse. Dat zien we meteen. Wij kunnen erg goed in groepen denken. We zien in één oogopslag of iets ergens bij hoort of niet. Vaak ontaardt dat helaas in pesten, discriminatie of oorlog. Maar meestal is het vermogen tot generaliseren een overlevingsstrategie. Elke voetganger die opnieuw moet uitvinden wat de eigenschappen zijn van een aanstormende metalen doos op wielen, is geen lang leven beschoren.

Objecten behoren niet tot één groep, maar tot een oneindig groot aantal. Een auto is niet alleen onderdeel van de groep ‘levensgevaarlijke metalen dozen’, maar ook van de groepen ‘vervoermiddelen’, ‘rode objecten’, ‘borreltafelonderwerpen’, ‘geldverslinders’, ‘benzinebranders’ en ‘lustobjecten’, om er maar een paar te noemen. Elk van deze groepen herbergt ook nog andere objecten, respectievelijk ‘koffer-met-bom’, ‘trein’, ‘biljartbal’, ‘sex’, ‘kind’, ‘molotov-cocktail’ en ‘buurvrouw’. Een object hoort bij een groep omdat het één of meerdere eigenschappen gemeenschappelijk heeft met de andere leden van die groep. In de wiskunde heet een groep een verzameling. In een programmeertaal is het een klasse.
Programmeurs bedenken ook objecten. Dingen die doen wat ze moeten doen. Met gedrag en eigenschappen die moeten passen in de situatie waarvoor ze bestemd zijn. Anders is het programma niet goed.

Een object is zich ‘bewust’ van de omgeving en kan daarop adequaat reageren. Dat is voor geprogrammeerde objecten in een virtuele wereld niet anders dan voor objecten die stuk gaan als je ze laat vallen. Objecten worden daarom ook wel voorgesteld als virtuele robots. Je kunt er van te voren intelligentie instoppen, maar op het moment dat ze aan het werk moeten, zullen ze op eigen kracht functioneren. Dat is ook zo met gebouwen en huisstijlen.

Ontwerpers die leren programmeren zien vanzelf de overeenkomsten. De ontwerper/programmeur moet vaststellen wat de relevante eigenschappen van een object zijn en met welke bijbehorende creatieve oplossingen het juiste resultaat bereikt kan worden. Net als in de echte wereld. Tot welke groepen behoort een ontwerp (tot de ‘goedkoopste’, de ‘beste’, de ‘snelste’ of de ‘nieuwste’) en als de eigenschappen van verschillende groepen met elkaar in conflict zijn, wat is de hiërarchie van de groepen dan? Zo’n indeling, het data model, is essentieel om objecten te kunnen programmeren. Het is de kunst om het model zodanig te ontwerpen, dat het in de toekomst weinigof geen aanpassing behoeft. Dat het in staat is om adequaat te reageren op een buitenwereld die we vaak nog niet in detail kennen als het object wordt bedacht. Dat vergt voortschrijdend inzicht. Programmeren is dus een ontwerpproces.

Laten we beginnen met iets eenvoudigs, het object ‘boek’ is onderdeel (een ‘instance’) van de klasse ‘Boek’ (naar goed programmeer gebruik wordt de naam van een object geheel in onderkast geschreven en de naam van de klasse met een beginkapitaal). Aan het boek kunnen we eigenschappen toekennen. Bijvoorbeeld een formaat, een titel, de inhoudsopgave, de inhoud, het colofon en de index. In de programmeertaal Python ziet dat er dan zo uit (alle tekst achter het ‘#’ teken wordt genegeerd omdat het als commentaar wordt gezien en eigenschappen worden in object-taal met een punt aan de naam van het object gevoegd):

---

boek = Boek()    # Maak een object van het type Boek, een boek dus
boek.formaat = (12, 18)    # Stel het boekformaat op 12 x 18 cm.
boek.titel = Het Subjectief    # Geeft het boek een titel
boek.omslag = Omslag()    # Maak een omslag object voeg het aan ons boek toe.
boek.inhoud = Inhoud()    # En maak ook een object met de inhoud (tekst en beeld) van alle pagina’s.
boek.colofon = Colofon()    # En ook een colofon

---

Het boek is nu af. Wat nu moet gebeuren is het beschrijven van de klasse Boek zelf. Als we de eigenschappen van de klasse juist hebben gedefinieerd, dan is het boek in staat om precies op de juiste wijze te reageren op instructies als boek.print(), waarbij het zichzelf afdrukt en boek.maakindex(), waarbij het boek van zichzelf een inhoudsopgave en alfabetische index genereert.
De implementatie van deze twee ‘methods’ (zoals functies in object-taal heten) die het boek nodig heeft, zouden er in Python als volgt uit kunnen zien:

---

class Boek:
  def print(self): # Definieer de print functie
    self.omslag.print() # Print het omslag
    self.inhoud.print() # Print alle pagina’s
    # Maak een index object met woord-paginanummer combinaties
    index = self.maakindex() 
    index.print() # Print de alfabetisch index

  def maakindex(self): # Definieer de functie die de index berekent
    index = Index() # Maak een index object
    for page in self.inhoud.pages: # Voor alle pagina’s van de inhoud
      for word in page: # Voor alle woorden in deze pagina
        # Bewaar de woord-paginanummer combinatie
        index.append(word, page.number) 
    return index # Geef het index object terug aan het object dat deze ‘method’ aangeroepen heeft.

---

Dit is voorlopig alles wat het boek moet kunnen.
Intussen hebben we wel vier nieuwe klassen (Omslag, Inhoud, Colofon en Index) geïntroduceerd die apart aandacht verdienen. Maar zoals met elk ontwerpproces hebben we het probleem, dat in eerste instantie groot en onoverzichtlijk leek, nu gereduceerd tot 4 kleinere. Dat is natuurlijk een understatement, maar toch niet minder waar. We kunnen het totale boekobject steeds verder opdelen, tot we alleen simpele problemen overhouden. Net zolang tot het geheel is teruggebracht tot deelprobleempjes die zich met standaard (typo)grafische middelen op laten lossen (Dat neemt natuurlijk niet weg dat het van essentieel belang is om ook het geheel in de gaten moet worden gehouden. Het totaal moet meer zijn dan alleen de som van de onderdelen).

Om het overzichtelijk te houden is de definitie van de klassen hier even weggelaten. Daar zit natuurlijk de crux, want de echte intelligente beslissingen over opmaak en alle typografische beslissingen zitten natuurlijk in die 4 klassen verborgen. Toch zal een ieder die de moeite neemt zich te verdiepen in de code kunnen zien dat er geen magie in zit. De aanpak dat met betrekkelijk eenvoudige middelen al een redelijk resultaat te boeken valt. Maar een ontwerper kan het natuurlijk altijd beter.
Het boek-programma is meer dan alleen academisch. Het werkt echt, zonder noemenwaardig veel toevoegingen. Het programma is in zijn geheel te downloaden van xml.petr.com/items/boek. Daar staat ook de link om DrawBot op te halen, de applicatie van Just van Rossum voor Mac OSX, waarin Python programma’s interactief kunnen worden uitgeprobeerd. Oorspronkelijk was het bedoeld als educatief gereedschap, maar steeds meer blijkt het uitstekend bruikbaar als schetsomgeving voor programmerende ontwerpers. Objectief gezien natuurlijk.
’