"Hallo, Amigo! Ik wil je graag vertellen over een ander voordeel van OOP. Zie je, programma's lijken meer op dieren dan op gebouwen. Ze worden niet gebouwd, ze worden gegroeid. Ontwikkeling betekent constante veranderingen. In de bouw kun je een goed plan hebben en dat tot in de puntjes uitvoeren. Maar bij softwareontwikkeling is dat niet het geval."

Heel vaak kun je iets niet doen zoals je van plan was, en moet je je programma vaak herwerken. En nog vaker veranderen de eisen van de klant.

"Maar wat als de klant een heel gedetailleerde specificatie verstrekt?"

"Kijk eens wat er in de loop van de tijd gebeurt. Als een product slaagt, wil de klant een nieuwe versie uitbrengen, en dan nog een, en nog een. En natuurlijk moet je een paar « kleine wijzigingen » aanbrengen om het bestaande product. Softwareontwikkeling is dus een lange reeks van veranderingen. Alleen de cadans verschilt. Elke week, eens per maand of elk half jaar komt er een nieuwe versie uit."

"Dus wat concluderen we uit dit alles?"

"De interne structuur van het product moet zo worden onderhouden dat grote (en kleine) wijzigingen kunnen worden aangebracht met minimale herbewerking."

"Hoe doe je dat?"

"We hebben al gesproken over hoe een programma bestaat uit objecten die met elkaar interageren. Laten we dikke stippen gebruiken om alle objecten van ons programma op het bord weer te geven. We zullen pijlen tekenen van elk object (stip) naar alle objecten (stippen) waarmee het samenwerkt."

Laten we nu de objecten (punten) in groepen combineren. Stippen behoren tot dezelfde groep als ze veel meer met elkaar verbonden zijn dan de andere stippen. Als de meeste pijlen van een punt naar punten in de groep wijzen, hebben we de objecten correct gegroepeerd. Van stippen binnen dezelfde groep wordt gezegd dat ze nauw gekoppeld zijn, terwijl stippen in verschillende groepen losjes gekoppeld zijn.

Dit wordt het « principe van losse koppeling » genoemd . Een programma wordt opgesplitst in verschillende delen, vaak lagen, waarvan de logica sterk verbonden is met hun interne structuur en zwak verbonden is met andere lagen/delen. Interactie tussen lagen is meestal sterk gecompartimenteerd. Een laag kan een andere laag aanroepen met slechts een kleine subset van zijn klassen.

"Hetzelfde principe van 'arbeidsverdeling', maar dan op grotere schaal?"

"Precies. Hierdoor kunnen we een afdeling reorganiseren, efficiënter maken en nog meer mensen aannemen, en als we de interdepartementale protocollen niet veranderen, zullen al onze veranderingen lokaal zijn. Niemand hoeft omgeschoold te worden. Dat doen we niet' "Je hoeft niet het hele systeem opnieuw te bewerken. Elke afdeling kan op deze manier zijn interne zaken optimaliseren als de mechanismen voor afdelingsinteractie goed worden gekozen."

'Als ze goed gekozen zijn. En wat als ze niet goed gekozen zijn?'

'Dan heb je al snel geen « bewegingsruimte » meer om wijzigingen aan te brengen en moet je het hele systeem herwerken. Dat gebeurt van tijd tot tijd. We kunnen de toekomst niet voorspellen, maar we kunnen het aantal keren dat we het programma moeten herschrijven tot een minimum beperken."

"Oké. Ik zie het voordeel van het opdelen van het programma, maar hoe komt OOP in beeld?"

“Als we kiezen hoe we de afdelingen structureren en hoe ze op elkaar inwerken, passen we het ‘ principe van abstractie ’ toe. Bij het programmeren wordt abstractie gebruikt om te bepalen hoe het programma het beste opgesplitst kan worden en hoe de onderdelen op elkaar moeten inwerken. Dit principe kan ook herhaaldelijk worden toegepast op de samenstellende delen totdat we het programma hebben opgesplitst in individuele klassen."

"En de interne structuur van deze onderdelen verbergen en strikt beperken hoe ze omgaan met andere onderdelen - dat is inkapseling , toch?"

"Precies. Inkapseling en abstractie zijn de hoekstenen van OOP. Een goed programma moet aan deze twee principes voldoen. Later zullen we andere principes bekijken en hun voordelen gaan begrijpen."

"Goed spul. Ik kan niet wachten!"