"Hej, Amigo! I dag vil jeg åbne en ny og interessant verden for dig. Jeg taler om objektorienteret programmering (OOP) . Du har allerede lært klasser og objekter at kende. I dag skal du afsted at lære mere om dem, meget mere."
Vi starter med de fire søjler i OOP. De er abstraktion, indkapsling, arv og polymorfi. (Der plejede at være tre, men abstraktion blev tilføjet senere)
1) Abstraktion.
Et godt eksempel på abstraktion i det virkelige liv er jobbeskrivelser i en virksomhed. En stillingsbetegnelse er én ting, men dens pligter er en helt anden sag.
Forestil dig, at du opretter organisationsdiagrammet for din fremtidige virksomhed. Du kan dele en sekretærs opgaver op og sprede dem på flere andre stillinger. Du kan opdele den administrerende direktørs job i flere separate stillinger: økonomichef, teknologichef, marketingchef, chef for menneskelige ressourcer. Eller du kan kombinere stillingerne som kontorchef og rekrutterer til én.
Antag, at du finder på navne til stillinger i din virksomhed, og så "disponerer" du ansvaret for disse stillinger. Det er abstraktion - at dele noget stort og monolitisk op i flere små dele.
Fra en programmørs perspektiv er abstraktion korrekt at opdele et program i objekter.
Et stort program kan normalt repræsenteres som interagerende objekter på et dusin forskellige måder. Abstraktion lader dig udvælge et objekts hovedkarakteristika og udelade noget mindre vigtigt.
Abstraktion er som en militær strategi. Hvis du vælger den forkerte strategi, vil ingen genial taktik redde dagen.
2) Indkapsling.
Indkapsling har til formål at forbedre interaktionen mellem objekter ved at forenkle dem.
Den bedste måde at forenkle noget på er at skjule noget kompliceret for dem, der ikke behøver at vide om det. For eksempel, hvis du satte dig bag pilotkontrollen på et Boeing-jetfly, ville det tage lang tid at forstå, hvordan de fungerer:
På den anden side ser alt mere simpelt ud for passagererne på flyet: De køber en billet og går ombord på flyet, som så letter og lander. Du kan nemt flyve fra kontinent til kontinent, idet du kun ved, hvordan du «køber en billet» og «border et fly». Vi ser ikke noget af kompleksiteten forbundet med at forberede flyet til flyvning, start, landing og forskellige potentielle nødsituationer. Og vi har ikke nævnt satellitnavigation, autopilot og flyvekontrolcentre. Dette forenkler vores liv.
Med hensyn til programmering er indkapsling at "skjule implementeringen". Jeg kan godt lide den definition. Vores klasse kan indeholde hundredvis af metoder og implementere meget kompleks adfærd i forskellige situationer. Men vi kan skjule alle dets metoder fra nysgerrige øjne (ved at markere dem som " private "), og efterlade kun to eller tre metoder til interaktion med andre klasser (ved at markere dem som " offentlige "). Så vil alle de andre klasser i vores program kun se - og kalde - disse få metoder på denne klasse . Hele klassens kompleksitet vil være skjult indeni, ligesom cockpittet holdes fra udsigten til glade passagerer.
3) Arv.
Arv er et begreb i programmering og 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) lav det, vi har brug for fra bunden, og bruger meget tid og kræfter på at gøre det.
2) lav det, vi har brug for, ved at bruge ting, der allerede eksisterer.
Den bedste strategi er denne: Vi tager en eksisterende god løsning, omarbejder og tilpasser den, så den opfylder vores behov, og bruger den derefter.
Overvej den menneskelige evolution. Hvis vi sporer deres begyndelse tilbage til begyndelsen af livet på planeten, ser vi, at der er gået milliarder af år. Men hvis vi tænker på mennesker som udgangspunkt fra aber, så er der kun gået et par millioner år. At skabe noget fra bunden tager længere tid. Meget længere.
På samme måde kan vi i programmering oprette en klasse baseret på en anden. Den nye klasse bliver en efterkommer (arving) af en eksisterende klasse. Dette er super nyttigt, når du allerede har en klasse, der indeholder 80-90% af de nødvendige data og metoder. Vi erklærer blot en passende klasse som forælder til vores nye klasse. Alle overordnede klasses data og metoder bliver automatisk en del af den nye klasse. Praktisk, ikke?
4) Polymorfi.
Polymorfisme er programmeringskoncept, der beskriver situationen, hvor forskellige implementeringer er skjult bag den samme grænseflade. For at finde en analog i det virkelige liv kan vi se på processen med at køre bil.
Hvis en person kan køre lastbil, kan han eller hun også blive sat bag rattet i en ambulance eller en sportsvogn. En person kan køre en bil, uanset hvilken slags bil det er, fordi de alle har den samme kontrolgrænseflade: et rat, pedaler og et gearskifte. Biler er organiseret forskelligt indeni, men de deler alle den samme kontrolgrænseflade.
Vend tilbage til programmering, polymorfi lader os interagere med objekter af forskellige klasser (normalt med en fælles forfader) på samme måde. Betydningen af dette kan ikke overbetones. Det bliver vigtigere, efterhånden som et program vokser sig større.
OOP er principper. Programmeringslove. Hver af dem begrænser os på en eller anden måde, men giver til gengæld enorme fordele, efterhånden som programmer vokser sig store. De fire principper i OOP er som de fire ben på en stol. Hvis du tager selv en af dem væk, bliver hele systemet ustabilt.