Share
Tot nu toe hebben we in deze reeks gesproken over objectgeoriënteerde programmering in het algemeen en het OOP-principe van cohesie. In dit artikel zullen we kijken naar het principe van koppelen en hoe het helpt bij de ontwikkeling van games.
Notitie: Hoewel deze tutorial geschreven is met behulp van Java, zou je in bijna elke game-ontwikkelomgeving dezelfde technieken en concepten moeten kunnen gebruiken.
Koppeling is het principe van "scheiding van belangen". Dit betekent dat één object de status of het gedrag van een ander object niet rechtstreeks wijzigt of wijzigt.
Koppeling kijkt naar de relatie tussen objecten en hoe nauw verbonden ze zijn. Een relatiediagram is een geweldige manier om de verbindingen tussen objecten te visualiseren. In een dergelijk diagram vertegenwoordigen vakjes objecten en pijlen geven een verbinding weer tussen twee objecten waarbij een object een ander object rechtstreeks kan beïnvloeden.
Een goed voorbeeld van koppeling is HTML en CSS. Voor CSS werd HTML gebruikt voor zowel opmaak als presentatie. Hierdoor ontstond een opgeblazen code die moeilijk te veranderen en moeilijk te onderhouden was. Met de komst van CSS werd HTML alleen gebruikt voor markup en CSS nam het over voor presentatie. Dit maakte de code redelijk schoon en gemakkelijk veranderbaar. De zorgen over presentatie en markup waren gescheiden.
Objecten die onafhankelijk van elkaar zijn en niet direct de toestand van andere objecten wijzigen, zouden dat wel zijn los verbonden. Losse koppeling maakt de code flexibeler, veranderlijker en gemakkelijker om mee te werken.
Objecten die afhankelijk zijn van andere objecten en die de toestanden van andere objecten kunnen wijzigen, zouden dat wel zijn strak gekoppeld. Strakke koppeling creëert situaties waarbij het wijzigen van de code van een object ook het wijzigen van de code van andere objecten vereist (ook bekend als een rimpeleffect). Nauw gekoppelde code is ook moeilijker te hergebruiken omdat deze niet kan worden gescheiden.
Een veelgebruikte uitdrukking die u zult horen is "streven naar lage koppeling en hoge cohesie". Deze zin is een nuttige herinnering dat we moeten streven naar code die taken scheidt en niet sterk afhankelijk is van elkaar. Dus een lage (of losse) koppeling is over het algemeen goed, terwijl een hoge (of strakke) koppeling over het algemeen slecht is.
Laten we eerst kijken naar de objecten van Asteroïden en hoe ze verbonden zijn. Bedenk dat de objecten een schip, een asteroïde, een vliegende schotel en een kogel zijn. Hoe zijn deze objecten gerelateerd of met elkaar verbonden?
In asteroïden kan een schip een kogel afvuren, een kogel kan een asteroïde en een vliegende schotel raken en een asteroïde en een vliegende schotel kunnen het schip raken. Ons relatieschema ziet er dan als volgt uit:
Zoals u kunt zien, zijn de objecten allemaal vrij goed met elkaar verbonden. Daarom moeten we voorzichtig zijn met hoe we de code schrijven, anders komen we in een nauw gekoppeld systeem terecht. Laat het bijvoorbeeld het schip nemen dat een kogel afvuurt. Als het schip een kogelobject zou maken, de positie ervan zou moeten volgen en dan de asteroïde zou moeten wijzigen wanneer de kogel raakt, zou ons systeem zeer strak gekoppeld zijn.
In plaats daarvan moet het schip een kogelobject maken, maar maak je er daarna geen zorgen over. Een andere klas zou verantwoordelijk zijn voor het bijhouden van de positie van de kogel en wat er gebeurt als een kogel een asteroïde raakt. Met een tussenklas tussen onze relaties zou het diagram er als volgt uitzien:
Dit relatieschema ziet er veel beter uit en creëert een heel losjes gekoppeld systeem. Als we in dit systeem een object zouden toevoegen, zoals een meteoor, zouden we dit eenvoudig kunnen doen zonder de functie van het schip of de kogelobjecten te hoeven veranderen - we zouden onze intermediaire klasse het allemaal laten regelen.
Aangezien er maar één object in Tetris is, de Tetrimino, is koppeling geen echt probleem, omdat er geen relaties met andere objecten kunnen zijn.
Voor Pac-Man kan een strakke koppeling optreden wanneer Pac-Man een krachtpellet eet. Wanneer een power pellet wordt gegeten, kan Pac-Man dan spoken eten en de status van de geest veranderen eetbaar. Als het Pac-Man-object zou volgen wanneer het een krachtpellet at en vervolgens de veranderingsstatus van elke geest zou initiëren, zou het systeem nauw gekoppeld zijn.
Nogmaals, een andere klasse is vereist om deze informatie bij te houden en te verwerken, zodat onze objecten los gekoppeld kunnen worden. Hieronder is een voorbeeld van hoe een intermediaire klasse Pac-Man kon volgen die een krachtpellet at.
/ ** * Intermediaire klasse die game-evenementen bijhoudt * / public class Game ... if (Pac-Man.eats (Power_Pellet)) Ghosts.changeState (); ...
Koppeling is het principe van het verminderen van hoe objecten direct de toestanden en het gedrag van andere objecten beïnvloeden. Koppeling helpt om code te maken die gemakkelijker te lezen is en die gemakkelijker te wijzigen is.
In de volgende Quick Tip bespreken we het principe van inkapseling en waarom het helpt bij het maken van onderhoudbare code. Volg ons op Twitter, Facebook of Google+ om op de hoogte te blijven van de laatste berichten.
Accentsconagua