1. Introduktion av principerna för OOP
Idag kommer du att upptäcka en ny och intressant värld. En värld av objektorienterad programmering ( OOP ). Du har tidigare lärt dig om klasser och föremål. Idag kommer du att lära dig mer om dem, mycket mer.
OOP uppstod som ett svar på den ökande komplexiteten i programmen. När variabler och metoder i program började uppgå till tiotusentals stod det klart att något måste göras. En lösning var att kombinera data och tillhörande metoder till separata objekt.
Nu var programmerare tvungna att separat beskriva hur objekt interagerar externt och hur de beter sig internt. Detta gjorde det mycket lättare att förstå och skriva program. Men en fråga kvarstod: vilka metoder ska vara interna i ett objekt och vilka ska vara tillgängliga för andra objekt?
Många tillvägagångssätt försöktes. Och baserat på den upptäckta bästa praxisen uppstod fyra principer för OOP . De är abstraktion, inkapsling, arv och polymorfism . Tidigare fanns det bara tre, men experter bestämde sig senare för att lägga till abstraktion också.
2. Abstraktion
Människor på Internet tvistar fortfarande om definitionen av abstraktion i OOP . Problemet är inte att alla har fel. Det är att alla har rätt . Ju mindre ett program är, desto mer abstraktion är knuten till Java-språket. Ju större ett program är, desto mer abstraktion är knuten till att modellera/förenkla verkliga objekt.
Men de bästa hjärnorna verkar vara överens om att:
Abstraktion är användningen av endast de egenskaper hos ett objekt som representerar det tillräckligt exakt i ett program. Huvudtanken är att representera objektet med den minsta uppsättningen av fält och metoder som samtidigt gör att dina uppgifter kan lösas med tillräcklig noggrannhet .
I Java åstadkoms abstraktion genom abstrakta klasser och gränssnitt.
Abstraktion i verkliga livet
Ett bra exempel på abstraktion i verkligheten är arbetsbeskrivningar på ett företag eller en organisation. Titeln på en position är en sak, men det specifika ansvaret som tilldelas en position är en helt annan sak.
Föreställ dig att du utformar organisationsstrukturen för ditt framtida företag. Du kan dela upp sekreteraransvaret och sprida dem på flera olika befattningar. Du kan dela upp vd-posten i flera separata positioner: CFO, CTO, CMO, HR Director. Eller så kan du till exempel kombinera tjänsterna som kontorschef och rekryterare till en.
Du tänker på jobbtitlar och delar sedan upp ansvaret för dessa positioner. Abstraktion är att bryta sig loss från objektet som helhet och välja de väsentliga egenskaper och komponenter som vi behöver.
Ur en programmeringssynpunkt är abstraktion den korrekta uppdelningen av ett program i objekt . Vanligtvis finns det dussintals sätt att representera ett stort program som interagerande objekt. Abstraktion låter dig välja de väsentliga egenskaperna och ignorera de icke väsentliga.
3. Inkapsling
Målet med inkapsling är att förbättra interaktioner genom att göra objekt enklare.
Och det bästa sättet att förenkla något är att dölja allt komplicerat för nyfikna ögon. Om du till exempel sätts in i cockpiten på ett Boeing jumbojet, kommer du inte omedelbart att förstå hur man använder det:
Men för passagerarna på planet är allt enklare: du köper en biljett och sätter dig på planet, som lyfter och sedan landar. Du kan enkelt flyga från en kontinent till en annan med bara möjligheten att "köpa en biljett" och "stiga på ett flyg". All komplexiteten med att förbereda flygplanet för flygning, start, landning och olika nödsituationer är dold för dig. För att inte tala om satellitnavigering, autopilot och flygledningscentraler. Och detta förenklar livet för oss.
Ur programmeringssynpunkt är inkapsling att "dölja implementeringen". Jag gillar den här definitionen. Vår klass kan innehålla hundratals metoder och implementera mycket komplexa beteenden i olika situationer. Men vi kan dölja alla dess metoder från nyfikna ögon (genom att markera dem med den privata modifieraren), och lämna bara två eller tre metoder för att interagera med andra klasser (genom att markera dem med den offentliga modifieraren). Då kommer alla andra klasser i vårt program bara att se de tre offentliga metoderna och anropa dem men inte andra. Och all komplexitet kommer att döljas i klassen, precis som cockpiten är gömd för glada passagerare.
4. Arv
Det finns två sidor av arv . Arv i programmering och arv i verkliga livet. Inom programmering är arv ett speciellt förhållande mellan två klasser . Men arv i verkligheten är mycket mer intressant.
Om vi behöver skapa något i verkligheten har vi två alternativ:
- Skapa det vi behöver från grunden, spendera mycket tid och ansträngning.
- Skapa det vi behöver utifrån något som redan finns.
Den optimala strategin är denna: ta en befintlig bra lösning, modifiera den lite, anpassa den för att passa våra behov och använd den sedan.
Om vi spårar mänsklighetens historia tillbaka till dess början, upptäcker vi att miljarder år har gått sedan livet började på planeten. Men om vi anser att utgångspunkten för människor är våra primatförfäder (dvs människor är "baserade på" primatförfäder), så har det bara gått ett par miljoner år. Att bygga från grunden tar längre tid. Mycket längre.
I programmering kan du göra något liknande genom att skapa en klass baserad på en annan. Den nya klassen härstammar från (ärver) den befintliga klassen. Detta är mycket fördelaktigt när en befintlig klass har 80-90% av de data och metoder vi behöver. Vi deklarerar helt enkelt den lämpliga klassen som förälder till vår nya klass, och alla data och metoder för den överordnade klassen visas automatiskt i den nya klassen. Bekvämt, eller hur?
5. Polymorfism
Polymorfism är ett programmeringskoncept. Den beskriver en situation där olika implementeringar är gömda bakom ett enda gränssnitt. När vi ser till det verkliga livet för en motsvarighet finner vi att det passar bra att köra ett fordon.
Om någon kan köra en lastbil, då kan hon också sättas bakom ratten i en ambulans eller bakom ratten i en sportbil. En person kan köra en bil, oavsett typ av bil, eftersom alla bilar har samma kontrollgränssnitt: en ratt, pedaler och växel. Bilarnas interna delar är olika, men de har alla samma kontrollgränssnitt.
För att återgå till programmeringsvärlden tillåter polymorfism att objekt av olika klasser (som vanligtvis har en gemensam förfader) kan nås på samma sätt, en egenskap vars värde knappast kan överskattas. Dess värde ökar när programmet växer sig större.
OOP betyder principer. Interna lagar. Var och en av dem begränsar oss på något sätt, men ger stora fördelar i gengäld när programmet blir stort. De fyra principerna för OOP är som fyra ben i ett bord. Ta bort en och hela systemet blir instabilt.
GO TO FULL VERSION