Vi är nästan färdiga med denna serie om objektorienterad programmering, och i den här artikeln diskuterar vi OOP-principen för abstraktion - det vill säga generalisering av ett objekt - och dess användning i spelutveckling.
Notera: Även om denna handledning skrivs med Java, bör du kunna använda samma tekniker och begrepp i nästan vilken spelutvecklingsmiljö som helst.
Abstraktion är generaliseringsprincipen. Detta kräver att vi flyttar från en specifik förekomst till ett mer generaliserat koncept genom att tänka på en objekts mest grundläggande information och funktion.
Det här låter lite konstigt, men vi är redan bekanta med begreppet abstraktion. Till exempel, om jag säger ordet "bil", vad tycker du om? Odds är att vi inte tänkte på samma bil. Jag tänkte på en svart Mustang Boss 302, som är en specifik förekomst av en bil. Ingen av oss hade fel på grund av ordet bil är ett mycket allmänt begrepp för ett fordon som vi använder för transport (eller rekreation i mitt fall).
Detsamma gäller videospel. Videospel kategoriseras i grupper som RTS, RPG, Racing, etc ... Dessa grupper är alla generella begrepp som beskriver spelets spel. StarCraft II, äldre Scrolls V: Skyrim och Need for Speed är alla specifika förekomster av dessa generaliserade begrepp.
Således tar abstraktion många specifika förekomster av objekt och extraherar sin gemensamma information och funktioner för att skapa ett enda generaliserat koncept som kan användas för att beskriva alla specifika fall som en.
Abstraktion är till hjälp för att den tar bort allt till de mest grundläggande principerna. Detta kan hjälpa till när man inkapslar funktionalitet för ett objekt eftersom det kan hjälpa till att identifiera viktig information som ska synas och den obetydliga informationen som kan göras gömd.
Abstraktion hjälper också till att inte upprepa sig självprincipen. Genom att ta vad en grupp objekt har gemensamt och abstrahera det kan vi hjälpa till att förhindra överflödig kod i varje objekt som i sin tur skapar mer underhållbar kod.
Låt oss, som tidigare, använda våra tre spel för att se några konkreta exempel på denna princip i aktion.
För att börja applicera abstraktion till Asteroider, tänk på dess föremål. Minns att föremålen för Asteroider var ett skepp, en asteroid, en flygande tallrik och en kula. Tänk nu på vad varje av dessa objekt har gemensamt. Delar de alla stater, beteenden eller funktionalitet? Genom att ta dessa gemensamma element som alla föremål delar, kan vi abstrahera dessa element i en mer generaliserad klass.
Till exempel skulle ett skepp, en asteroid, en flygande tallrik och en kula alla dela samma beteende för att flytta över skärmen. Du kan abstrahera detta beteende till en abstrakt klass som håller de gemensamma egenskaperna som behövs för att flytta ett objekt. Dessa kvaliteter skulle vara stater som placera och hastighet, och beteendet hos rör på sig.
Den abstraherade klassen i Java kan se ut som följande:
/ ** * Abstrakt klass för flyttning * / abstrakt klass Flyttbar offentlig float hastighetX; offentlig flythastighet; offentlig float positionX; offentliga float positionY; / ** * Funktion - utför uppgift (uppgift) för att flytta Ship * / public void move () positionX + = hastighetX; positionY + = hastighetY;
Det finns andra vanliga tillstånd, beteenden och funktionalitet som alla objekten delar. Kan du tänka på dem? Dessa kan alla läggas till i en abstrakt klass.
En sak du vill se upp för är att skapa en blob-klass. En blob-klass är vilken klass som helst som försöker hantera allt från en grupp objekt, även om varje objekt inte delar samma tillstånd, beteenden och funktionalitet. Bara för att ett skepp och en flygande tallrik kan skjuta betyder inte att du borde placera det beteendet i samma abstrakta klass som används för att beskriva alla fyra objekten.
Kolla in Iain Lobbs handledning om enhetskomposition för en titt på hur han undviker denna situation.
Som sagt många gånger tidigare har Tetris bara ett objekt, en Tetrimino. Detta förhindrar dock inte att Tetris abstraherar någon av dess funktionalitet. En Tetrimino är ritad på nästan samma sätt som spelplanen och andra spelbilder. Det innebär att du kan sammanfatta detta ritningsbeteende i en enda klass som alla saker som dras till skärmen hör till.
(Personligen gillar jag att ringa en sådan klass utdragbar
, men Sprite
är också ett vanligt namn.)
Pac-Man är lite mer intressant när det gäller abstraktion. Pac-Man, ett spöke och en pac-punkt delar inte riktigt några vanliga tillstånd, beteenden eller funktionalitet. De kan dras till skärmen på samma sätt, så en abstrakt klass för hanteringsteckning kan skapas, men inte mycket mer än så. Så vad gör du? I det här fallet är det helt bra att skapa flera abstrakta klasser för att organisera koden.
Börja med klassen för att hantera ritning för alla tre objekten. Ta sedan bort pac-punkten från gruppen eftersom det är objektet som verkligen inte hör hemma med de andra. Det lämnar Pac-Man och ett spöke. Tänk nu på vad dessa två objekt har gemensamt och skapa en annan abstrakt klass för dessa objekt. Denna klass kan innehålla stater som riktning och fart, och beteendet hos rör på sig.
Med två abstrakta klasser reducerar du den redundanta koden som skulle ha behövts för att skapa de tre objekten och flytta den till en plats som enkelt kan ändras och ändras.
Principen för abstraktion bidrar till att minska överflödig kod och skapa mer underhållbar kod. Emellertid gör abstraktion i sig ingenting om vi inte gör någonting med de abstraherade klasserna. För detta behöver vi lära oss mer om arv som kommer att diskuteras i nästa och sista artikeln i denna serie.
Följ oss på Twitter, Facebook eller Google+ för att hålla dig uppdaterad med de senaste inläggen.