Waarom hebben we OOP nodig?

1. Bedrijfsgeschiedenis

Ik wil je een verhaal vertellen dat laat zien hoe OOP helpt bij het bestrijden van de complexiteit van grote systemen. Dit is nodig om het doel van OOP te begrijpen .

Er was eens een klein bedrijf dat intergalactische scheepvaartdiensten leverde...

Laten we het Galaxy Rush noemen. Er werkten 5 mensen. De een werkte op de financiële afdeling, de tweede in een magazijn, de derde deed de leveringen, de vierde deed de reclame en de vijfde leidde de hele onderneming.

Het waren zeer harde werkers en slaagden in alles. Het bedrijf had een goede reputatie en verdiende veel geld. Maar elk jaar kwamen er meer en meer bestellingen, dus moest de baas extra personeel aannemen. Nog een aantal voor het magazijn, nog een aantal voor leveringen, nog een voor financiën en een extra reclame-expert om het marktaandeel van het bedrijf uit te breiden.

En toen begonnen de problemen. Er waren meer mensen en ze begonnen elkaar in de weg te lopen.

De marketeer besteedt de bankrekening leeg aan een nieuwe reclamecampagne, dus er is geen geld om producten aan te schaffen die dringend verzonden moeten worden.

Het magazijn heeft 10 gloednieuwe hyperdrives die eens per maand naar een klant worden verzonden. Een koerier kwam aangevlogen en nam een ​​hyperdrive mee voor een andere klant, waardoor de reguliere bestelling van 10 hyperdrives een maand vertraging opliep. De eerste koerier wist gewoon niet dat de andere bestelling door die tweede koerier werd uitgevoerd.

De nieuwe assistent-manager stuurt een koerier weg op een ruimteschip om meer goederen te kopen. Ondertussen wacht alle anderen tot er een beschikbaar ruimteschip verschijnt. Er zijn talloze spoedleveringen, maar deze assistent houdt alleen toezicht op de inkoop en probeert haar werk goed te doen. Hoe beter een werknemer zijn taken uitvoert, hoe meer hij zich bemoeit met het werk van anderen.

Bij het analyseren van de situatie realiseert de baas zich dat belangrijke middelen zoals het ruimteschip, geld en producten niet optimaal worden gebruikt. In plaats daarvan zijn ze onderworpen aan de regel "u snooze, u verliest". Elke werknemer kan een hulpbron innemen die alle anderen nodig hebben voor hun werk, waardoor de andere werknemers en het bedrijf als geheel in gevaar worden gebracht.

Er moest iets gebeuren, dus besloot de baas het monolithische bedrijf op te splitsen in een paar afdelingen. Hij creëerde een verzendafdeling, een marketingafdeling, een inkoopafdeling, een financiële afdeling en een voorraadafdeling. Niet langer kon iemand zomaar het ruimteschip innemen. Het hoofd van de expeditieafdeling ontving alle informatie over de leveringen en gaf het schip uit aan de koerier met de meest winstgevende bestelling. Bovendien stond het magazijn niet toe dat koeriers zomaar alle goederen konden meenemen die ze wilden. In plaats daarvan werd het picken van producten uit het magazijn een gecontroleerd proces. De financiële afdeling zou geen geld vrijmaken voor een marketingcampagne als ze wist dat er binnenkort een aankoop zou plaatsvinden. Elke afdeling had één publiek gezicht: het afdelingshoofd.De interne structuur van elke afdeling was zijn eigen zaak. Als een koerier producten wilde halen, ging ze naar de magazijnbeheerder, niet naar het magazijn. Als er een nieuwe bestelling binnenkwam, werd deze ontvangen door het hoofd van de verzendafdeling ( public-facing representative) en niet door een koerier ( someone not authorized to interact with the other departments).

Met andere woorden, de baas consolideerde de middelen en acties met middelen in groepen (afdelingen) en verbood ook anderen zich te bemoeien met de interne structuren van afdelingen. Interdepartementale interacties moesten via een specifieke persoon verlopen.

Vanuit het oogpunt van OOP is dit niets meer dan het opdelen van het programma in objecten. Een monolithisch programma van methoden en variabelen wordt een programma bestaande uit objecten. En de objecten hebben variabelen en methoden.

Het probleem was dat elke werknemer met elke hulpbron kon werken en commando's kon geven aan elke andere werknemer, allemaal zonder toezicht of controle. We legden een kleine beperking op, maar kregen meer orde. En we konden ook alles beter controleren.

Dit is verdeel en heers in zijn puurste vorm.

2. Hoe programma's worden gemaakt

Ik wil nog een belangrijk punt aanstippen dat een ander voordeel van OOP onthult . Zie je dat programma's meer op dieren lijken dan op gebouwen? Ze zijn niet gebouwd. Ze zijn gegroeid. Ontwikkeling is constante verandering. In de bouw kun je een goed plan hebben en dat nauwkeurig uitvoeren. Bij softwareontwikkeling is dat niet het geval.

Heel vaak kun je tijdens het programmeren iets niet doen zoals je oorspronkelijk van plan was en moet je veel herwerken. De eisen van de klant veranderen nog vaker.

Maar wat als de klant een heel precieze specificatie geeft? Dat maakt het nog erger. Bekijk wat er in de loop van de tijd met het product gebeurt.

Het succes van het product zal ertoe leiden dat de klant een nieuwe versie wil uitbrengen, en dan nog een en nog een. En natuurlijk hoeft u alleen maar "kleine wijzigingen" aan het bestaande product toe te voegen. Je ziet dus dat productontwikkeling een aaneenschakeling is van constante veranderingen. Alleen de tijdschaal is anders. Eens per week, eens per maand of eens in de zes maanden kan een nieuwe versie worden uitgebracht.

En welke conclusie kunnen we hieruit trekken? De interne structuur van het product moet zodanig worden onderhouden dat er significante (en kleine) wijzigingen kunnen worden aangebracht met minimale aanpassingen.

Objectcohesie

Maar dat doen is moeilijker dan beslissen om het te doen. We zeiden al dat een programma bestaat uit objecten die met elkaar interageren. Laten we alle objecten van ons programma op het bord tekenen en ze in punten weergeven. En laten we pijlen trekken van elk object (punt) naar alle andere objecten (punten) waarmee het samenwerkt.

Nu combineren we de objecten (punten) in groepen. Punten moeten worden gegroepeerd als de onderlinge verbindingen veel intenser zijn dan die met andere punten. Als de meeste pijlen van een punt naar andere punten in zijn eigen groep gaan, dan zijn de groepen correct gevormd. We zeggen dat de punten binnen een groep een hoge cohesie hebben , terwijl punten in verschillende groepen een lagere cohesie hebben.

Loskoppelingsprincipe

Er is een "principe van losse koppeling". Een programma is opgedeeld in verschillende onderdelen, die vaak gelaagd zijn. De logica van deze lagen/delen is nauw verbonden met hun interne structuur en heel losjes gekoppeld aan andere lagen/delen. Interacties tussen lagen zijn meestal erg gereguleerd. Eén laag kan verwijzen naar de tweede laag en slechts een kleine subset van zijn klassen gebruiken. Dit is het principe van "het bedrijf opdelen in afdelingen" dat we eerder zagen, maar dan op grotere schaal.

Het resultaat is dat we een afdeling naar behoefte kunnen reorganiseren om de effectiviteit ervan te vergroten en dat we nog meer mensen voor de afdeling kunnen aannemen, en zolang we het protocol van interactie met onze andere afdelingen niet veranderen, zullen alle aangebrachte veranderingen lokaal blijven. Niemand hoeft iets opnieuw te leren. U hoeft niet het hele systeem opnieuw te bewerken. Elke afdeling kan dit soort interne optimalisatie uitvoeren als de mechanismen voor interdepartementale interactie goed gekozen zijn.

Goed gekozen. Maar wat als ze niet goed gekozen zijn? Dan is het verandervermogen snel uitgeput en moet je het hele systeem opnieuw doen. Dit moet van tijd tot tijd worden gedaan. Je kunt de toekomst niet voorspellen, maar je kunt het aantal herhalingen tot een minimum beperken.

Principe van abstractie

Kiezen hoe afdelingen zijn gestructureerd en hoe ze met elkaar omgaan, is het " principe van abstractie ". Bij het programmeren wordt het gebruikt om de beste manier te bepalen om een ​​programma op te splitsen in samenstellende delen en hoe die delen moeten samenwerken. We kunnen het principe opnieuw toepassen en de resulterende onderdelen in delen verdelen, totdat we het programma hebben opgesplitst in afzonderlijke klassen.

Het verbergen van de interne structuur van deze onderdelen en het strikt beperken van interacties met andere onderdelen is inkapseling . Inkapseling en abstractie zijn hoekstenen van OOP . Een goed programma moet aan deze twee principes voldoen. In de toekomst zullen we de rest van de principes bekijken en onderzoeken welke voordelen ze bieden.