1. Selskapets historie
Jeg vil fortelle deg en historie som viser hvordan OOP hjelper deg med å kjempe med kompleksiteten til store systemer. Dette er nødvendig for at du skal forstå formålet med OOP .
Det var en gang et lite selskap som leverte intergalaktiske frakttjenester...
La oss kalle det Galaxy Rush. Det sysselsatte 5 personer. En jobbet med finans, den andre jobbet på et lager, den tredje leverte, den fjerde håndterte reklame, og den femte ledet hele bedriften.
De var veldig hardtarbeidende og lyktes med alt. Selskapet hadde et godt rykte og tjente mye penger. Men hvert år ble det flere og flere bestillinger, så sjefen måtte ansette flere ansatte. Flere til lageret, flere til leveranser, en til for økonomi, og en ekstra annonseekspert for å utvide selskapets markedsandel.
Og det var da problemene startet. Det var flere mennesker , og de begynte å komme i veien for hverandre.
Markedsførerens forbruk tapper bankkontoen på en ny reklamekampanje, så det er ingen penger til å kjøpe produkter som må sendes raskt.
Lageret har 10 splitter nye hyperstasjoner som sendes til en kunde en gang i måneden. En kurer fløy inn og tok bort en hyperstasjon for en annen klient, noe som førte til at den vanlige bestillingen på 10 hyperstasjoner ble forsinket med en måned. Den første kureren visste rett og slett ikke om den andre bestillingen ble fylt av den andre kureren.
Den nye assisterende lederen sender en kurer avgårde på et romskip for å kjøpe flere varer. I mellomtiden venter alle andre på at et tilgjengelig romskip skal dukke opp. Det er tonnevis av hasteleveranser, men denne assistenten fører kun tilsyn med innkjøp og prøver å gjøre jobben sin godt. Jo bedre en ansatt utfører pliktene sine, jo mer forstyrrer han andres arbeid.
Ved å analysere situasjonen innser sjefen at viktige ressurser som romskipet, kontanter og produkter ikke blir brukt optimalt. I stedet er de underlagt regelen «du slumrer, du taper». Enhver ansatt kan ta en ressurs som alle andre trenger for sitt arbeid, og dermed sette de andre ansatte og selskapet som helhet i fare.
Noe måtte gjøres, så sjefen bestemte seg for å dele det monolittiske selskapet i noen få avdelinger. Han opprettet en fraktavdeling, en markedsavdeling, en innkjøpsavdeling, en økonomiavdeling og en lageravdeling. Ingen lenger kunne bare ta romskipet. Sjefen for fraktavdelingen mottok all informasjon om leveransene og utstedte skipet til budet med den mest lønnsomme bestillingen. I tillegg tillot ikke lageret kurerer å bare ta varer de ville ha. I stedet ble det å plukke produkter fra lageret en kontrollert prosess. Økonomiavdelingen ville ikke frigjøre midler til en markedsføringskampanje hvis den visste at det ville bli et kjøp snart. Hver avdeling hadde ett offentlig ansikt - avdelingslederen.Hver avdelings interne struktur var sin egen virksomhet. Hvis en kurer ønsket å få produkter, gikk hun til lagersjefen, ikke til lageret. Hvis en ny bestilling kom inn, ble den mottatt av lederen for fraktavdelingen ( public-facing representative) og ikke av en kurer ( someone not authorized to interact with the other departments).
Med andre ord, sjefen konsoliderte ressursene og handlingene som involverer ressurser i grupper (avdelinger) , og forbød også andre å blande seg inn i avdelingenes interne strukturer. Samhandlinger mellom avdelingene måtte gå gjennom en bestemt person.
Fra OOPs synspunkt er dette ikke noe annet enn å dele opp programmet i objekter. Et monolitisk program av metoder og variabler blir et program som består av objekter. Og objektene har variabler og metoder.
Problemet var at enhver ansatt kunne jobbe med hvilken som helst ressurs og gi kommandoer til enhver annen ansatt, alt uten tilsyn eller kontroll. Vi påla en liten begrensning, men oppnådde mer orden. Og vi kunne også bedre kontrollere alt.
Dette er splitt-og-hersk i sin reneste form.
2. Hvordan programmer lages
Jeg vil komme inn på et viktig punkt som avslører en annen fordel med OOP . Ser du at programmer er mer som dyr enn bygninger? De er ikke bygget. De er voksne. Utvikling er konstant endring. I konstruksjon kan du ha en god plan og følge den med presisjon. Dette er ikke tilfelle med programvareutvikling.
Svært ofte i programmering kan du ikke gjøre noe slik du opprinnelig hadde tenkt og må omarbeide mye. Kundekrav endres enda oftere.
Men hva om kunden ga en veldig presis spesifikasjon? Det gjør ting enda verre. Ta en titt på hva som skjer med produktet over tid.
Produktets suksess vil føre til at kunden ønsker å gi ut en ny versjon, og så en og en til. Og, selvfølgelig, alt du trenger å gjøre er å legge til "små endringer" i det eksisterende produktet. Så du kan se produktutvikling er en sekvens av konstante endringer. Bare tidsskalaen er annerledes. En ny versjon kan slippes en gang i uken, en gang i måneden eller en gang hver sjette måned.
Og hvilken konklusjon kan vi trekke av alt dette? Produktets interne struktur må opprettholdes på en måte som gjør at betydelige (og mindre) endringer kan gjøres med minimal omarbeiding.
Objektsammenheng
Men å gjøre det er vanskeligere enn å bestemme seg for å gjøre det. Vi har allerede sagt at et program består av objekter som samhandler med hverandre. La oss tegne alle programmets objekter på tavlen, representere dem med poeng. Og la oss tegne piler fra hvert objekt (punkt) til alle de andre objektene (punktene) som det samhandler med.
Nå skal vi kombinere objektene (punktene) i grupper. Poeng bør grupperes hvis forbindelsene mellom dem er mye mer intense enn de med andre poeng. Hvis de fleste pilene fra et punkt går til andre punkter i sin egen gruppe, ble gruppene riktig dannet. Vi sier at punktene innenfor en gruppe har høy kohesjon mens poeng i ulike grupper har lavere kohesjon.
Løskoblingsprinsipp
Det er et "prinsipp om løs kobling". Et program er delt inn i flere deler, som ofte er lag. Logikken til disse lagene/delene er tett koblet til deres indre struktur og veldig løst koblet til andre lag/deler. Interaksjoner mellom lag er vanligvis svært regulerte. Ett lag kan referere til det andre laget og bruke bare en liten delmengde av klassene. Dette er prinsippet om å «dele bedriften inn i avdelinger» vi så tidligere, men i større skala.
Resultatet er at vi kan omorganisere en avdeling etter behov for å øke effektiviteten og vi kan ansette enda flere personer til avdelingen, og så lenge vi ikke endrer protokollen for samhandling med våre andre avdelinger, vil alle endringene som gjøres forbli lokalt. Ingen trenger å lære noe på nytt. Du trenger ikke å omarbeide hele systemet. Hver avdeling kan foreta denne typen intern optimalisering dersom mekanismene for interdepartemental interaksjon er godt valgt.
Godt valgt. Men hva om de ikke er godt valgt? Da er endringskapasiteten raskt oppbrukt og du må gjøre om hele systemet. Dette må gjøres fra tid til annen. Du kan ikke forutsi fremtiden, men du kan holde antallet gjenta på et minimum.
Abstraksjonsprinsippet
Å velge hvordan avdelinger er strukturert og hvordan de samhandler er " abstraksjonsprinsippet ". I programmering brukes den til å bestemme den beste måten å dele et program inn i komponenter og hvordan disse delene skal samhandle. Vi kan bruke prinsippet på nytt, og dele de resulterende delene inn i deler, til vi har delt opp programmet i individuelle klasser.
Å skjule den interne strukturen til disse delene og strengt begrense interaksjoner med andre deler er innkapsling . Innkapsling og abstraksjon er hjørnesteinene i OOP . Et godt program må følge disse to prinsippene. I fremtiden vil vi se på resten av prinsippene og utforske hvilke fordeler de gir.