Hvorfor har vi brug for OOP?

1. Virksomhedens historie

Jeg vil gerne fortælle dig en historie, der viser, hvordan OOP hjælper med at kæmpe med kompleksiteten af ​​store systemer. Dette er nødvendigt for at du kan forstå formålet med OOP .

Der var engang et lille firma, der leverede intergalaktiske forsendelsestjenester...

Lad os kalde det Galaxy Rush. Det beskæftigede 5 personer. Den ene arbejdede med finans, den anden arbejdede på et lager, den tredje stod for leverancerne, den fjerde stod for reklame, og den femte styrede hele virksomheden.

De var meget hårdtarbejdende og lykkedes med alt. Virksomheden havde et godt ry og tjente mange penge. Men hvert år kom der flere og flere ordrer, så chefen måtte ansætte yderligere medarbejdere. Flere til lageret, flere til leverancer, en mere til økonomi og en ekstra annonceekspert for at udvide virksomhedens markedsandel.

Og det var der, problemerne startede. Der var flere mennesker , og de begyndte at komme i vejen for hinanden.

Markedsførerens forbrug dræner bankkontoen på en ny annoncekampagne, så der er ingen penge til at købe produkter, der akut skal sendes.

Lageret har 10 helt nye hyperdrev, der bliver sendt til en kunde en gang om måneden. En kurer fløj ind og tog et hyperdrev væk for en anden klient, hvilket medførte, at den almindelige ordre på 10 hyperdrev blev forsinket med en måned. Den første kurer vidste simpelthen ikke om den anden ordre blev udfyldt af den anden kurer.

Den nye assisterende manager sender en kurer afsted på et rumskib for at købe flere varer. I mellemtiden venter alle andre på, at et ledigt rumskib dukker op. Der er tonsvis af presserende leverancer, men denne assistent fører kun tilsyn med indkøb og forsøger at gøre sit arbejde godt. Jo bedre en medarbejder udfører sine opgaver, jo mere blander han sig i andres arbejde.

Ved at analysere situationen indser chefen, at vigtige ressourcer som rumskibet, kontanter og produkter ikke bliver brugt optimalt. I stedet er de underlagt reglen "du slumrer, du taber". Enhver medarbejder kunne tage en ressource, som alle andre har brug for til deres arbejde, og dermed bringe de øvrige medarbejdere og virksomheden som helhed i fare.

Noget skulle gøres, så chefen besluttede at opdele den monolitiske virksomhed i nogle få afdelinger. Han oprettede en shippingafdeling, en marketingafdeling, en indkøbsafdeling, en økonomiafdeling og en lagerafdeling. Ingen kunne længere blot tage rumskibet. Lederen af ​​shippingafdelingen modtog alle oplysninger om leverancerne og udstedte skibet til kureren med den mest rentable ordre. Derudover tillod lageret ikke kurerer blot at tage de varer, de ønskede. I stedet blev plukning af produkter fra lageret en kontrolleret proces. Økonomiafdelingen ville ikke frigive midler til en marketingkampagne, hvis den vidste, at der snart ville være et køb. Hver afdeling havde ét offentligt ansigt - afdelingslederen.Hver afdelings interne struktur var dens egen sag. Hvis en kurer ville have produkter, gik hun til lagerchefen, ikke til lageret. Hvis der kom en ny ordre, blev den modtaget af lederen af ​​forsendelsesafdelingen ( public-facing representative) og ikke af en kurer ( someone not authorized to interact with the other departments).

Med andre ord konsoliderede chefen ressourcerne og handlingerne, der involverede ressourcer, i grupper (afdelinger) og forbød også andre at blande sig i afdelingernes interne strukturer. Interdepartementale interaktioner skulle gå gennem en bestemt person.

Fra OOPs synspunkt er dette ikke andet end at opdele programmet i objekter. Et monolitisk program af metoder og variabler bliver til et program bestående af objekter. Og objekterne har variabler og metoder.

Problemet var, at enhver medarbejder kunne arbejde med enhver ressource og give kommandoer til enhver anden medarbejder, alt sammen uden tilsyn eller kontrol. Vi pålagde en lille begrænsning, men opnåede mere orden. Og vi var også i stand til bedre at kontrollere alt.

Dette er del-og-hersk i sin reneste form.

2. Hvordan programmer oprettes

Jeg vil gerne komme ind på endnu et vigtigt punkt, der afslører en anden fordel ved OOP . Kan du se, at programmer er mere som dyr end bygninger? De er ikke bygget. De er vokset. Udvikling er konstant forandring. I byggeriet kan du have en god plan og følge den med præcision. Dette er ikke tilfældet med softwareudvikling.

Meget ofte i programmering, kan du ikke gøre noget, som du oprindeligt havde tænkt dig og skal arbejde meget om. Kundekrav ændres endnu oftere.

Men hvad nu hvis kunden gav en meget præcis specifikation? Det gør tingene endnu værre. Tag et kig på, hvad der sker med produktet over tid.

Produktets succes vil føre til, at kunden vil udgive en ny version, og så endnu en og en til. Og det eneste du skal gøre er selvfølgelig at tilføje "små ændringer" til det eksisterende produkt. Så du kan se produktudvikling er en sekvens af konstante ændringer. Kun tidsskalaen er anderledes. En ny version kan udgives en gang om ugen, en gang om måneden eller en gang hver sjette måned.

Og hvilken konklusion kan vi drage af alt dette? Produktets interne struktur skal vedligeholdes på en måde, der tillader væsentlige (og mindre) ændringer med minimal efterbearbejdning.

Objektsammenhæng

Men at gøre det er sværere end at beslutte sig for at gøre det. Vi har allerede sagt, at et program består af objekter, der interagerer med hinanden. Lad os tegne alle vores programs objekter på tavlen og repræsentere dem med punkter. Og lad os tegne pile fra hvert objekt (punkt) til alle de andre objekter (punkter), som det interagerer med.

Nu vil vi kombinere objekterne (punkterne) i grupper. Punkter bør grupperes, hvis forbindelserne mellem dem er meget mere intense end dem med andre punkter. Hvis de fleste af pilene fra et punkt går til andre punkter i sin egen gruppe, så var grupperne dannet korrekt. Vi siger, at punkterne i en gruppe har høj sammenhængskraft , mens punkter i forskellige grupper har lavere sammenhængskraft.

Løskoblingsprincip

Der er et "princip for løs kobling". Et program er opdelt i flere dele, som ofte er lag. Logikken i disse lag/dele er tæt koblet til deres indre struktur og meget løst koblet til andre lag/dele. Interaktioner mellem lag er normalt meget regulerede. Et lag kan referere til det andet lag og kun bruge en lille delmængde af dets klasser. Det er princippet om at "opdele virksomheden i afdelinger", vi så tidligere, men i større skala.

Resultatet er, at vi kan omorganisere en afdeling efter behov for at øge dens effektivitet, og vi kan ansætte endnu flere folk til afdelingen, og så længe vi ikke ændrer protokollen for interaktion med vores andre afdelinger, så vil alle de ændringer, der foretages, forblive lokalt. Ingen skal lære noget igen. Du behøver ikke at omarbejde hele systemet. Hver afdeling kan foretage denne form for intern optimering, hvis mekanismerne for interafdelingens interaktion er velvalgte.

Godt valgt. Men hvad hvis de ikke er udvalgt godt? Så er kapaciteten til forandring hurtigt opbrugt, og du bliver nødt til at lave hele systemet om. Dette skal gøres fra tid til anden. Du kan ikke forudsige fremtiden, men du kan holde antallet af gentagelser på et minimum.

Abstraktionsprincip

At vælge, hvordan afdelinger er struktureret, og hvordan de interagerer, er " abstraktionsprincippet ". I programmering bruges det til at bestemme den bedste måde at opdele et program i bestanddele, og hvordan disse dele skal interagere. Vi kan genanvende princippet ved at opdele de resulterende dele i dele, indtil vi har opdelt programmet i individuelle klasser.

At skjule den indre struktur af disse dele og strengt begrænse interaktioner med andre dele er indkapsling . Indkapsling og abstraktion er hjørnestenene i OOP . Et godt program skal følge disse to principper. I fremtiden vil vi se på resten af ​​principperne og undersøge, hvilke fordele de giver.