Objectoriëntatie en daarmee objectgeoriënteerd programmeren is het idee dat software gestructureerd dient te worden aan de hand van verschillende soorten objecten, die tevens objecten in de echte wereld vertegenwoordigen. Het staat naast andere ideeën over softwarestructuren waaronder bijvoorbeeld 'functioneel programmeren' waarin software een bundel van functies is, eventueel gesorteerd in modules. Het primaire idee van objectoriëntatie is dat functionaliteiten van de software ondergebracht dienen te worden bij die objecten die daarvoor het meest geschikt zijn. De ontwerpdiscussies rond objectoriëntatie gaan dus meestal over "Welke objecten zijn er?" en "Bij welk object brengen we een bepaalde functionaliteit onder?". De theorie zegt dat objectoriëntatie natuurlijker is omdat onze echte wereld ook vol zit met objecten en het denken in de structuur van de software dan het meest lijkt op het denken zoals we dat gewend zijn in de echte wereld. In de praktijk blijkt dit deels waar te zijn, mogelijk is niet alles in de echte wereld een object, en tevens is objectoriëntatie toch nog erg lastig om heel goed te doen en heeft het een erg steile leercurve. Om objectoriëntatie goed toe te passen is er een aantal grondbeginselen, zijn er veel voorkomende ontwerppatronen en bestaan er vele principes. De principes zijn goed om over na te denken, maar zijn optioneel, je kunt overleggen met andere softwareontwikkelaars over welke principes je wel volgt en welke niet, en onderbouwen waarom je zo kiest. De ontwerppatronen adresseren een specifiek probleem, echter wanneer je dat probleem hebt, wordt verwacht dat je het patroon correct toepast (en anders niet!). De grondbeginselen zijn niet optioneel en daaraan dien je je altijd te houden, want strijdig zijn met de grondbeginselen betekent eigenlijk dat je niet objectgeoriënteerd werkt.
Grondbeginselen
Afhankelijk van de bron (en de tijdsgeest waarin het geschreven is) kun je verschillende grondbeginselen vinden over objectoriëntatie, echter in grote lijnen kom je altijd de volgende drie dingen tegen "iets over klassen en types", "iets over encapsulatie", "iets over verschillende verschijningsvormen (polymorfisme, overerving, compositie)". Hieronder een toelichting bij deze drie grondbeginselen.
Klassen definiëren types
In objectoriëntatie gaat het natuurlijk over objecten. Echter, objecten zijn altijd van een bepaald type, en dat type definieert de natuur van het object. Deze typeaanduiding noemen we een klasse. Een voorbeeld: Ik bestel bij een fietsenwinkel een fiets, met een prijs, model, kleur enz. Vanaf dat moment is er specifiek 1 object in de echte wereld dat mijn fiets vertegenwoordigt. In de software van de fietsenwinkel is er dan ook specifiek 1 object dat mijn fiets vertegenwoordigt. Een object is altijd concreet, het gaat specifiek over 1 ding en alle informatie die dat object heeft is bepaald. Je kunt aan dit object zien wat de prijs is (950 euro), wat het model is (omafiets), wat de kleur is (blauw), enz. Stel je nu voor dat de fietsenwinkel voor elke verkoop een object aanmaakt in het softwaresysteem en dus invoert wat de concrete aspecten van die fiets zijn. In dat geval zou het handig zijn als het softwaresysteem een attributenset kent, die tezamen het concept van een fiets vormen, denk aan: Elke fiets heeft een model, prijs, kleur enz. Het vastleggen van de definitie van een object (en dus niet het object zelf) noemen we typeren. Bij de meeste objectgeoriënteerde programmeertalen wordt een type vastgelegd in een klasse. Er zijn dus klassen die definiëren wat het ding in de echte wereld is, en er zijn objecten die de dingen in de echte wereld concreet vertegenwoordigen. Er is een klasse Fiets waarin staat dat elke fiets een prijs, model en kleur heeft, maar niet welke prijs, model en kleur. En er zijn objecten van het type Fiets die voor specifieke fietsen concreet aangeven welke prijs, model en kleur deze fiets heeft, bijvoorbeeld mijn blauwe omafiets van 950 euro.
Encapsulatie
In het woord encapsulatie zit het woord capsule, wat je misschien kent uit de medische wereld. Een medicijn dat in een capsule zit heeft een werkende stof aan de binnenkant en een huls die ervoor zorgt dat het geheel bijeen blijft en op de juiste plek in je lichaam tot werking komt. Wanneer, waar en hoe de huls opent is exact bepaald om te zorgen dat de capsule niet eerder al open gaat en het medicijn op de verkeerde plek in je lichaam terecht komt, maar ook om te zorgen dat de inhoud van de capsule niet "vervuild" wordt door externe invloeden. Het grondbeginsel over encapsulatie in objectoriëntatie heeft eigenlijk hetzelfde doel. Een object dient een capsule te zijn, waarbij de gegevens die samen het object vertegenwoordigen, beschermd worden door een huls. In objectgeoriënteerd programmeren doe je dit meestal door de gegevens van het object aan de binnenkant op te slaan (net als de capsule) en deze te markeren met een privé-indicator (meestal het woord private) en de operaties op deze gegevens te markeren met een publiek-indicator (meestal het woord public), waarbij de operatie tevens valideert dat deze niet onterecht gebruikt wordt. Denk hierbij aan de huls van de capsule die ervoor zorgt dat het moment van opengaan correct is. Een object is dus een minisysteem dat zowel de gegevens van het object vasthoudt, maar ook de verantwoordelijkheid heeft dat deze gegevens gedurende de uitvoer van de software consistent en correct blijven. Het object kan dit doen doordat de gegevens en de controle samen 1 geheel vormen (de capsule). Encapsulatie betekent dus eigenlijk dat alle gegevens die tezamen het object vertegenwoordigen, en alle operaties op deze gegevens, bij elkaar in 1 enkele klasse gedefinieerd dienen te worden.
Polymorfisme
Het grondbeginsel polymorfisme zegt dat elk object afhankelijk van context verschillende verschijningsvormen kan hebben. De woorden "poly" en "morf" zijn Grieks en betekenen "veel" en "vorm". Dit klinkt misschien in eerste instantie gek, zeker als je aan de dingen in de echte wereld denkt, want een fiets verandert eigenlijk niet van vorm en blijft toch altijd een fiets, maar toch is dit niet helemaal waar. Natuurlijk verandert de fiets niet van vorm, maar ik kan mijn definitie aanpassen zodat de vorm van de fiets daarbij past en de fiets een andere verschijningsvorm heeft. In objectoriëntatie is er een hiërarchische structuur van objecten. Hier een voorbeeld: Stel je voor dat ik mijn fiets plots een 'tweewieler' noem, dan is dat niet verkeerd, want een fiets is een tweewieler, en het object dat in mijn schuur staat heeft er ook geen probleem mee om zichzelf als 'tweewieler' voor te doen. De verschijningsvorm van mijn fiets is veranderd. Echter naast mijn fiets staat ook een brommer, en dat is ook een tweewieler. En stel dat ik beide deze objecten nu 'vervoersmiddel' noem, dan begint de auto die voor mijn huis staat zich ook ineens aangesproken te voelen. Je kunt deze keten hiërarchisch en steeds abstracter doorlopen tot je uiteindelijk uitkomt bij iets als 'ding'. Alles is een ding. In de objectoriëntatie noemen we dat 'object', alles is uiteindelijk een object. Door met deze hiërarchische structuur handig om te gaan is het mogelijk om stukken programmacode te hergebruiken. Een simpel voorbeeld: stel dat mijn fiets, brommer en auto allemaal een operatie hebben die een persoon verplaatst, dan zou ik die operatie kunnen plaatsen in een klasse Vervoersmiddel en de klassen Fiets, Brommer en Auto kunnen vertellen dat zij allen vervoersmiddelen zijn. Hierdoor hoef ik het verplaatsen van personen maar 1 keer te programmeren en kunnen alle afgeleide klassen deze gebruiken. Zelfs al zouden de vervoersmiddelen de operatie op een verschillende manier uitvoeren, dan is het nog handig om te weten dat zij allen dezelfde functie (verplaats een persoon) kunnen adresseren. Polymorfisme stelt objecten in staat om zich abstracter voor te doen, zodat zij problemen van een abstractere orde kunnen adresseren: "Het maakt me niet uit hoe ik vandaag bij mijn werk kom, welk object is geschikt?" Het antwoord is dan: Alle vervoersmiddelen. Dit is een gemakkelijker antwoord dan: alle fietsen, en alle brommers, en alle auto's, en alle helikopters, enz enz.
Conclusie
Objectoriëntatie is een denkmodel voor het structuren van software, dat objecten van een gedefinieerd type centraal stelt. Deze objecten opereren geëncapsuleerd en verbergen hun interne gegevens achter publiek bereikbare operaties die ervoor zorgen dat de gegevens in het object consistent en correct blijven. In het denkmodel bestaat een hiërarchie van types die van het meest abstractie niveau "object" uitloopt tot de meest concrete vorm van objecten die je zelf definieert in klassen. Hierdoor is het mogelijk dat een object van een lager type zichzelf voordoet als een object van een hoger type, zodat het problemen van een abstractere order kan adresseren zonder dat het nodig is de concrete oplossing te kennen.