Objektorienteret programmering

1. Introduktion af principperne for OOP

I dag vil du opdage en ny og interessant verden. Verden af ​​objektorienteret programmering ( OOP ). Du har tidligere lært om klasser og objekter. I dag vil du lære mere om dem, meget mere.

OOP opstod som et svar på den stigende kompleksitet af programmer. Da variabler og metoder i programmer begyndte at tælle titusinder, stod det klart, at noget måtte gøres. En løsning var at kombinere data og tilhørende metoder til separate objekter.

Nu skulle programmører separat beskrive, hvordan objekter interagerer eksternt, og hvordan de opfører sig internt. Dette gjorde det meget lettere at forstå og skrive programmer. Der var dog et spørgsmål tilbage: hvilke metoder skal være interne i et objekt, og hvilke skal være tilgængelige for andre objekter?

Mange tilgange blev forsøgt. Og baseret på de opdagede bedste praksisser opstod 4 principper for OOP . De er abstraktion, indkapsling, arv og polymorfi . Tidligere var der kun tre, men eksperter besluttede senere også at tilføje abstraktion.

2. Abstraktion

Folk på internettet skændes stadig om definitionen af ​​abstraktion i OOP . Problemet er ikke, at alle tager fejl. Det er, at alle har ret . Jo mindre et program er, jo mere abstraktion er bundet til Java-sproget. Jo større et program er, jo mere abstraktion er bundet til modellering/forenkling af objekter fra den virkelige verden.

Men de bedste hoveder synes at være enige om, at:

Abstraktion er kun brugen af ​​de karakteristika ved et objekt, der repræsenterer det tilstrækkeligt nøjagtigt i et program. Hovedideen er at repræsentere objektet med det mindste sæt af felter og metoder, der samtidig gør det muligt at løse dine opgaver med tilstrækkelig nøjagtighed .

I Java opnås abstraktion gennem abstrakte klasser og grænseflader.

Abstraktion i det virkelige liv

Et godt eksempel på abstraktion i det virkelige liv er jobbeskrivelser hos en virksomhed eller organisation. Titlen på en stilling er én ting, men de specifikke ansvarsområder, der er tildelt en stilling, er en helt anden sag.

Forestil dig, at du designer den organisatoriske struktur for din fremtidige virksomhed. Du kan opdele sekretæransvaret og sprede dem på flere forskellige stillinger. Du kan opdele CEO-stillingen i flere separate stillinger: CFO, CTO, CMO, HR Director. Eller du kan for eksempel kombinere stillingerne som kontorchef og rekrutterer til én.

Du udtænker jobtitler og opdeler derefter ansvaret for disse stillinger. Abstraktion er at bryde væk fra objektet som helhed og udvælge de væsentlige egenskaber og komponenter, som vi har brug for.

Fra et programmeringssynspunkt er abstraktion den korrekte opdeling af et program i objekter . Typisk er der snesevis af måder at repræsentere ethvert stort program som interagerende objekter. Abstraktion lader dig vælge de væsentlige egenskaber og ignorere de ikke-essentielle.

3. Indkapsling

Målet med indkapsling er at forbedre interaktioner ved at gøre objekter enklere.

Og den bedste måde at forenkle noget på er at skjule alt kompliceret for nysgerrige øjne. For eksempel, hvis du bliver sat ind i cockpittet på en Boeing jumbojet, vil du ikke umiddelbart forstå, hvordan du betjener den:

Men for passagererne på flyet er alt enklere: Du køber en billet og stiger på flyet, som letter og derefter lander. Du kan nemt flyve fra et kontinent til et andet med kun muligheden for at "købe en billet" og "stige på et fly". Al kompleksiteten ved at forberede flyet til flyvning, start, landing og forskellige nødsituationer er skjult for dig. For ikke at nævne satellitnavigations-, autopilot- og flyvekontrolcentrene. Og det forenkler livet for os.

Fra et programmeringssynspunkt er indkapsling at "skjule implementeringen". Jeg kan godt lide denne definition. Vores klasse kan indeholde hundredvis af metoder og implementere meget kompleks adfærd i forskellige situationer. Men vi kan skjule alle dens metoder fra nysgerrige øjne (ved at markere dem med den private modifikator), og kun lade to eller tre metoder interagere med andre klasser (ved at markere dem med den offentlige modifikator). Så vil alle andre klasser i vores program kun se de tre offentlige metoder og kalde dem, men ikke andre. Og al kompleksiteten vil være gemt inde i klassen, ligesom cockpittet er skjult for glade passagerer.

4. Arv

Der er to sider af arv . Arv i programmering og arv i det virkelige liv. I programmering er arv et særligt forhold mellem to klasser . Men arv i det virkelige liv er langt mere interessant.

Hvis vi skal skabe noget i det virkelige liv, har vi to muligheder:

1. Skab det, vi har brug for fra bunden, og brug en masse tid og kræfter.
2. Skab den ting, vi har brug for, baseret på noget, der allerede eksisterer.

Den optimale strategi er denne: Tag en eksisterende god løsning, modificer den lidt, juster den, så den passer til vores behov, og brug den derefter.

Hvis vi sporer menneskets historie tilbage til dens begyndelse, opdager vi, at der er gået milliarder af år, siden livet begyndte på planeten. Men hvis vi betragter menneskers udgangspunkt som vores primatforfædre (dvs. mennesker er "baseret på" primatforfædre), så er der kun gået et par millioner år. Det tager længere tid at bygge fra bunden. Meget længere.

I programmering kan du gøre noget lignende ved at oprette en klasse baseret på en anden. Den nye klasse nedstammer fra (arver) den eksisterende klasse. Dette er meget fordelagtigt, når en eksisterende klasse har 80-90% af de data og metoder, vi har brug for. Vi erklærer simpelthen den passende klasse som forælder for vores nye klasse, og alle data og metoder for overordnet klasse vises automatisk i den nye klasse. Praktisk, ikke?

5. Polymorfi

Polymorfi er et programmeringskoncept. Den beskriver en situation, hvor forskellige implementeringer er skjult bag en enkelt grænseflade. Ser vi ud i det virkelige liv for en modpart, finder vi ud af, at det passer godt at betjene et køretøj.

Hvis nogen kan køre lastbil, så kan hun også sættes bag rattet i en ambulance eller bag rattet i en sportsvogn. En person kan betjene en bil, uanset hvilken slags bil, fordi alle biler har den samme kontrolgrænseflade: et rat, pedaler og gearskifte. Bilernes indre er forskellige, men de har alle det samme kontrolinterface.

For at vende tilbage til programmeringsverdenen tillader polymorfi objekter af forskellige klasser (som normalt har en fælles forfader) at blive tilgået på samme måde, en egenskab hvis værdi næppe kan overvurderes. Dets værdi stiger, efterhånden som programmet vokser sig større.

OOP betyder principper. Interne love. Hver af dem begrænser os på en eller anden måde, men giver store fordele til gengæld, når programmet bliver stort. De fire principper i OOP er som fire ben på et bord. Tag en væk, og hele systemet bliver ustabilt.