Varför behöver vi OOP?

1. Företagets historia

Jag vill berätta en historia som visar hur OOP hjälper till att bekämpa komplexiteten hos stora system. Detta är nödvändigt för att du ska förstå syftet med OOP .

Det var en gång ett litet företag som tillhandahöll intergalaktiska frakttjänster...

Låt oss kalla det Galaxy Rush. Den sysselsatte 5 personer. En arbetade med ekonomi, den andra arbetade på ett lager, den tredje skötte leveranserna, den fjärde skötte reklam och den femte skötte hela företaget.

De var väldigt hårt arbetande och lyckades med allt. Företaget hade ett gott rykte och tjänade mycket pengar. Men varje år kom det fler och fler beställningar, så chefen fick anställa ytterligare medarbetare. Flera till för lagret, flera till för leveranser, en till för ekonomi och ytterligare en annonsexpert för att utöka företagets marknadsandel.

Och det var då problemen började. Det var fler människor och de började komma i vägen för varandra.

Marknadsförarens utgifter tömmer bankkontot på en ny reklamkampanj, så det finns inga pengar för att köpa produkter som akut måste skickas.

Lagret har 10 helt nya hyperdiskar som skickas till en kund en gång i månaden. En kurir flög in och tog bort en hyperdrive för en annan kund, vilket gjorde att den vanliga beställningen på 10 hyperdriven blev försenad med en månad. Den första kuriren visste helt enkelt inte om den andra beställningen fylldes av den andra kuriren.

Den nya assisterande chefen skickar iväg en kurir på ett rymdskepp för att köpa mer varor. Samtidigt väntar alla andra på att ett tillgängligt rymdskepp ska dyka upp. Det finns massor av brådskande leveranser, men den här assistenten övervakar bara upphandlingen och försöker göra sitt jobb bra. Ju bättre en anställd utför sina arbetsuppgifter, desto mer stör han andras arbete.

När chefen analyserar situationen inser han att viktiga resurser som rymdskeppet, kontanter och produkter inte används optimalt. Istället omfattas de av regeln "du snooze, du förlorar". Vilken anställd som helst skulle kunna ta en resurs som alla andra behöver för sitt arbete och därmed äventyra de andra anställda och företaget som helhet.

Något måste göras, så chefen bestämde sig för att dela upp det monolitiska företaget i några avdelningar. Han skapade en fraktavdelning, en marknadsavdelning, en inköpsavdelning, en ekonomiavdelning och en lageravdelning. Ingen längre kunde bara ta rymdskeppet. Chefen för fraktavdelningen fick all information om leveranserna och utfärdade fartyget till kuriren med den mest lönsamma beställningen. Dessutom tillät lagret inte kurirer att helt enkelt ta alla varor de ville ha. Plockningen av produkter från lagret blev istället en kontrollerad process. Ekonomiavdelningen skulle inte släppa pengar för en marknadsföringskampanj om den visste att det skulle bli ett köp snart. Varje avdelning hade ett offentligt ansikte - avdelningschefen.Varje avdelnings interna struktur var sin egen verksamhet. Om en kurir ville få produkter gick hon till lagerchefen, inte till lagret. Om en ny beställning kom in togs den emot av chefen för fraktavdelningen ( ) public-facing representativeoch inte av en kurir ( someone not authorized to interact with the other departments).

Med andra ord konsoliderade chefen resurserna och åtgärderna som involverade resurser i grupper (avdelningar) och förbjöd även andra att störa avdelningarnas interna strukturer . Interaktioner mellan avdelningarna måste gå genom en specifik person.

Ur OOPs synvinkel är detta inget annat än att dela upp programmet i objekt. Ett monolitiskt program av metoder och variabler blir ett program som består av objekt. Och objekten har variabler och metoder.

Problemet var att vilken anställd som helst kunde arbeta med vilken resurs som helst och ge kommandon till vilken annan anställd som helst, allt utan tillsyn eller kontroller. Vi införde en liten begränsning, men uppnådde mer ordning. Och vi kunde också bättre kontrollera allt.

Detta är dela-och-härska i sin renaste form.

2. Hur program skapas

Jag vill beröra ytterligare en viktig punkt som avslöjar en annan fördel med OOP . Ser du att program är mer som djur än byggnader? De är inte byggda. De är odlade. Utveckling är ständig förändring. Inom byggandet kan du ha en bra plan och följa den med precision. Så är inte fallet med mjukvaruutveckling.

Mycket ofta i programmering kan du inte göra något som du ursprungligen tänkt dig och måste omarbeta mycket. Kundernas krav förändras ännu oftare.

Men vad händer om kunden lämnade en mycket exakt specifikation? Det gör saken ännu värre. Ta en titt på vad som händer med produkten över tiden.

Produktens framgång kommer att leda till att kunden vill släppa en ny version, och sedan en och en till. Och, naturligtvis, allt du behöver göra är att lägga till "små ändringar" i den befintliga produkten. Så du kan se produktutveckling är en sekvens av ständiga förändringar. Bara tidsskalan är annorlunda. En ny version kan släppas en gång i veckan, en gång i månaden eller en gång var sjätte månad.

Och vilken slutsats kan vi dra av allt detta? Produktens interna struktur måste bibehållas på ett sätt som gör att betydande (och mindre) ändringar kan göras med minimal omarbetning.

Objektsammanhållning

Men att göra det är svårare än att bestämma sig för att göra det. Vi har redan sagt att ett program består av objekt som interagerar med varandra. Låt oss rita alla vårt programs objekt på tavlan och representera dem med poäng. Och låt oss rita pilar från varje objekt (punkt) till alla andra objekt (punkter) som det interagerar med.

Nu ska vi kombinera objekten (punkterna) i grupper. Punkter bör grupperas om kopplingarna mellan dem är mycket intensivare än de med andra punkter. Om de flesta av pilarna från en punkt går till andra punkter i den egna gruppen, så bildades grupperna korrekt. Vi säger att punkterna inom en grupp har hög sammanhållning medan poäng i olika grupper har lägre sammanhållning.

Löskopplingsprincip

Det finns en "princip om lös koppling". Ett program är uppdelat i flera delar, som ofta är lager. Logiken hos dessa lager/delar är tätt kopplad till deras inre struktur och mycket löst kopplad till andra lager/delar. Interaktioner mellan lager är vanligtvis mycket reglerade. Ett lager kan referera till det andra lagret och endast använda en liten delmängd av dess klasser. Det är principen att "dela upp företaget i avdelningar" vi såg tidigare, men i större skala.

Resultatet är att vi kan omorganisera en avdelning efter behov för att öka dess effektivitet och vi kan anställa ännu fler personer till avdelningen, och så länge vi inte ändrar protokollet för interaktion med våra andra avdelningar, kommer alla ändringar som görs att förbli lokal. Ingen behöver lära sig någonting igen. Du behöver inte omarbeta hela systemet. Varje avdelning kan göra denna typ av intern optimering om mekanismerna för interdepartemental interaktion är väl valda.

Väl vald. Men vad händer om de inte är väl valda? Då är förändringskapaciteten snabbt uttömd och du måste göra om hela systemet. Detta måste göras då och då. Du kan inte förutsäga framtiden, men du kan hålla antalet omställningar till ett minimum.

Abstraktionsprincipen

Att välja hur avdelningar är uppbyggda och hur de samverkar är " abstraktionsprincipen" . I programmering används det för att bestämma det bästa sättet att dela upp ett program i beståndsdelar och hur dessa delar ska interagera. Vi kan återanvända principen, dela upp de resulterande delarna i delar, tills vi har delat upp programmet i individuella klasser.

Att dölja den interna strukturen hos dessa delar och strikt begränsa interaktioner med andra delar är inkapsling . Inkapsling och abstraktion är hörnstenar i OOP . Ett bra program måste följa dessa två principer. I framtiden kommer vi att titta på resten av principerna och utforska vilka fördelar de ger.